You don't need an SPA to use XHR, and your description of the SPA experience for the end user is a fantasy - there's a reason pretty progress bars are popular in SPAs, and it's not because of fast state changes, quite the reverse.
It's funny, your example actually shows the primary benefit of an SPA, and doesn't do anything to show any downsides. A progress bar is a perfect example. You can't show a progress bar with HTML. You would have clicked something, and a new page would be rendered entirely. In the time it took to create the new page on the backend, the user would be staring at either a white screen or the current page. If they're looking at the current page, they probably think the application is malfunctioning, as no user feedback was given to their action.
Whereas, with an SPA, you can _instantly_ show a progress bar, at least indicating that something is going on. And, the very fact that you're showing a progress bar means that the client side rendering isn't the slow action, it's retrieving something from the server. So, the UI was as interactive as possible.
This is an amazing feature you simply don't need on the majority of web apps, because a) the browser has a loading indicator and b) most web apps are fast enough to not need to tell the user about it, they just load new pages in milliseconds instead.
An in-page progress bar is in most cases a failure of UX, not a success.
