Someone I know wants to use diconnected recordsets in an application. To me it sounds like if I have a ORM tool there would really be no need to even touch disconnected recordsets. The way I understand it with ORM the ORM takes care of not hugging connections for unnecessarily long amounts of time, solving the need for a disconnected recordset. Is there an instance in which you would still want to use a disconnected recordset?
A fabricated ADO recordset can be a good choice of container object for data, as an alternative to a VBA Type (struct), Collection, Dictionary, etc i.e. strongly data typed nullable fields** with built-in support for filtering, sorting, searching, output to formatted text/xml/array, paging , cloning, etc. A fabricated ADO recordset is disconnected by definition.
Perhaps this isn't quite what you had in mind but it is a valid answer to your question i.e. an example of when you would still want to use a disconnected recordset, even though you have an ORM.
** Similary, ADO Parameter objects are a usual alternative for the Variant type in that, unlike VB intrinsic types, they can be both strongly data typed and nullable.