Notes to slide 9 (add a operation to query using a WS-Enumeration):

OGSA-DAI is doing a very similar thing by buffering the result set in memory
and allowing clients to return part of it at a time. This does however not
help performance since the same amount of data is returned in the end.
The main reason for this proposal was not performance but scalability, 
especially the size of the SOAP messages that are returned for large result
sets.

Some DBs allow you to use cursors to return results, WS-Enumeration would fit
in nicely with that. 

WS-Enumeration is part of the WS-Transfer stack, in WS-RF you would create
a new resource and use that to return the result in smaller packets.
Can WS-Enumeration be used outside the WS-Transfer stack?

A RUSReplyTooBig fault is a good thing to have, however it can be difficult to
use, most implementation just behave very rude when they run out of memory
(e.g. just go offline, or reply with authentication/authorization faults).
One caution is that this is a very dynamic fault, so even a query with only one
record could be a too big if another very large query is under processing.

The operation could be tied together with the query operation if you allow
for an extra parameter specifying the maximum size of the result and allowing
the server to either return the result or a WS-Enumeration in case the result
size exceeded the maximum.
The important point here is that the server cannot make this decision 
unilaterally, the client must also be able to specify its limitations.