> The user could have gotten logged out somehow, or maybe there's a rate limit or something
All your examples are retryable errors in which the prescription is the same: "keep the message queued until it's successful." And when all your failure modes are like this optimistic-no-feedback works. If you have non-retryable errors in your failure modes "Bad Request", "Gone" this pattern can't be used.
Sure they're retryable. But those retries might never succeed (user wipes their phone or uninstalls the app or logs out or clears local app data or a buffer fills up to come up with a few scenarios. Either the request didn't matter to the user at all, in which case sure whatever, or at some point they're going to discover that the thing they thought happened didn't actually happen.
All your examples are retryable errors in which the prescription is the same: "keep the message queued until it's successful." And when all your failure modes are like this optimistic-no-feedback works. If you have non-retryable errors in your failure modes "Bad Request", "Gone" this pattern can't be used.