Mostly agree with #1, but I don't understand #2. You're saying delivering plain, pre-rendered HTML is too fast for the client, so we shouldn't use it (especially in a thread about energy use on mobile)?
Using JS for partial page updates (whether that's a full single-page app or something smaller) has the potential to consume fewer network resources across multiple interactions.
Has the potential to ... but in practice, no. Websites which do this overwhelmingly use "best practices" frameworks, libraries, packers, minifiers, and up with an extremely dense 1 MiB javascript bundle, while the meaningful html/text of the page is less than 10 KiB. Images are bigger but the need to load / ability to cache is the same in either situation. And be careful that your api responses are not huge json blobs with more information than the page needs ...
Modern webpages use all the latest best techniques, and lose the performance race by miles, over and over again. Nobody is interested or enabled to clean up the mess, just to try to add more big-bang optimizations on top, after we get a few more features which users hate crammed on top ...
The truth is we had the technology for extremely efficient computation 10 years ago. New technology is nice, I like it, but we don't need it. But also, it doesn't matter. Simple gluttony and sloth will overwhelm any efficiency improvements.