Alternatively, I could suggest that CPU is cheaper than bandwidth, especially on mobile, so not sending a full html document with every request and just sending the required data and updating via JS makes much more sense for mobile.
Although this article is mostly about javascript on the server, and so isn't focussing on the fat js sites that you are talking about.
Bandwidth is a deferred cost. CPU is an immediate cost (on a mobile device).
When you run a CPU-sucking stie on your device, you typically know exactly which site or app is the culprit - you can watch your battery drop and feel your CPU heat up.
When you get your bill at the end of the month, it's a lot less clear why, exactly, that happened. And - fairly or not - it's a lot less likely to be blamed on a lightweight site that grabs extra data.
Not that these two things should be mutually exclusive anyway: an app designed for mobile will do most of its processing on the server with short bursts on the client, and ALSO be optimized for data on the server side. (The server, after all, typically knows what kind of client it's serving.)
Although this article is mostly about javascript on the server, and so isn't focussing on the fat js sites that you are talking about.