How does this address the problem of not saving user-submitted data after informing them you've done precisely that? This seems _very_ bad.
I think we're debating the merits of different classes of update here. Some updates are not essential (UI preferences, etc.), but other requests by their very nature, are--billing, messaging, draft editing, etc.
It would be "very bad" for some types of applications and not for others. Clicking "Save" on some complex document is the type of thing where you probably want to report "saving..." and then "saved" only after confirmation back from the server, but for a lot of simple operations that you know should almost always succeed (especially if you're doing something with websockets and you are tracking connected state, so you have a pretty reasonable expectation that you're able to communicate with the server in the next 1s), the best approach is often to assume they're going to succeed, update the UI as if they've succeeded, then if they fail, make sure to call attention to that unexpected case and put the UI back in the right state.
This is just one of the default mechanisms of Meteor. You can also construct regular calls to the server which do not have latency compensation (specifically, by having your update code exist on the server only).
I think we're debating the merits of different classes of update here. Some updates are not essential (UI preferences, etc.), but other requests by their very nature, are--billing, messaging, draft editing, etc.