A naively built app will do things like take some user input from a form, send it off to an API and await the response, and then update the UI when if the request is successful or display an error if there's a problem. That means the user has to wait for the request to complete before moving on to their next task. In other words, the DOM update waits for the network. If you have a slow connection that feels horrible (snarky frontend dev note - if you build a server-side rendered app it's how everything in the app works. Sucks if you have a slow connection.)
It's better for the user if the UI assumes the request has been successful and updates the UI with a temporary success state, and then undoes the update if the request fails and gives the user the option to recover their update and try again. Most of the time there won't be a problem (especially with good client side validation) so they'll never see the recover state, and they'll never need to wait for a network request to finish either. Obviously you shouldn't use that sort of UX pattern for critical things though.
Ugh, this has got to be one of my biggest bugbears with SPAs. This pattern fails far more than you obviously think it does, and when it does fail, it's usually handled so poorly it's worse than the 'cure' you're peddling.
Give me a clean, server-side form submission any day over the "has it worked, hasn't it?" inconsistency of SPAs.
It's better for the user if the UI assumes the request has been successful and updates the UI with a temporary success state, and then undoes the update if the request fails and gives the user the option to recover their update and try again. Most of the time there won't be a problem (especially with good client side validation) so they'll never see the recover state, and they'll never need to wait for a network request to finish either. Obviously you shouldn't use that sort of UX pattern for critical things though.