Having a way to query the collection for the most recent resume token is extremely useful for providing that on server startup to clients who are being sent initial data and then relying on the resume tokens to keep them 'up to date' and in 'real time', even after a disconnect.
ServerA makes rare changes to CollectionA via some mechanism.
ServerB provides an endpoint which allows BrowserB to get all documents from CollectionA and keep up to date with any changes(via change streams) made to the collection(whether via other Browsers interacting with ServerB, or the occasional update ServerA makes). However, no update has been made yet to CollectionA, so when the initial CollectionA is queried for all docs, BrowserB gets it, but ServerB does not have a resume token to send along after it is done(no updates have been made to CollectionA yet).
ServerB crashes, disconnecting from BrowserB
BrowserB is trying to reconnect to ServerB
ServerA makes an update to CollectionA
ServerB starts up again, no updates since start so no resume token for CollectionA
BrowserB reconnects, but has no resume token.
At this point, since ServerB was unable to send to BrowserB the current resume token for CollectionA right after initially sending the collection, nobody knows where to resume from, and the entire collection will have to be resent, rather than taking advantage of the resumability of change streams.
If ServerB was able to ask for CollectionA's resume token and pass that along with the end of streaming the documents intially, then BrowserB would simply reconnect to the newly up server, providing it's resume token, and catch back up from where it left off, getting the update from ServerA and moving on along.
The only way to hack around this that I know of is to force an update to a document on server up to get a resume token so you can send that along to anyone who requests streaming. Providing the capability to simply ask for what was the last resume token for a given collection prevents the need for this ugly hack.