Then the user goes away on a week's holiday and leaves their PC at your "next" button.
This exactly. Cursors have limited functionality that isn't directly disruptive to the database in general. At the very least, the transaction ID reservation necessary to preserve a cursor long-term can wreak havoc on your transaction ID wraparound if you have a fairly busy database. I can't think of a single situation where either client caching or LIMIT/OFFSET can't supplant it with better risk levels and costs.
A good solution to this general problem is "hitlists." I wrote about this concept before:
