Gmail is the one in a thousand or ten-thousand exception, not the rule. Frankly, I prefer the classic HTML version better. Quickbooks Online is an example of the opposite end of the spectrum. That is a steaming pile of crap. With that being said, the spectrum of applications that should be implemented as SPA's is really quite small. Let's layer on top of that the fact that an average developer can't get it right and we're left with the potential for a huge mess.
Now, let's talk about updating the three bytes. First, there is nothing wrong with using some AJAX to update those three bytes. Second, an entire page of HTML is what, 50KB. After the server gzips the text stream, it's about half that, if not less. Third, if most of my functionality is on the server, then all of my tests run in the same environment. Conversely, if half the functionality is on the server and half the functionality is on the browser, my testing environment now looks something like:
OMG, we haven't even talked about security. With an SPA, half of you app is running on the user's machine and the code is in clear text JavaScript (i.e. can be modified). Basically, any security on the client needs to be duplicated perfectly on the server, in a different language, and probably using different logic. All of that needs to be tested thoroughly.
Also, the attack surface for an SPA is going to be really big compared to a MPW due to the fact that most of the guts of the application are publicly accessible via a REST API. Literally, almost every field of every data object in your app ends up being exposed on the internet. The is in direct contrast to a MPW which interacts with the world via some simple GET and POST parameters.
Now let's talk about intellectual property. If I have every field of every data object in your application and I also know all of the relationships between them, then I own the architecture of your application. I know all of the database fields, table names, and relationships between the data. I know this because I had to diagram it all out when I created an internal application that integrated with the QuickBooks Online API. Like most API's, they make pretty much every table accessible via JSON and a REST API. Given a team of about a dozen devs, I could recreate a version of QuickBooks Online in about a year.