Well, if they just served html, they'd still only need to serve the content (and the viewer, the web browser, would indeed be cached in the form of an installed application on the end user's system).
The content can be served as a JSON object containing just the post and the metadata. If you scale up to millions of requests, suddenly you're saving a lot of bandwidth by not sending the same header, sidebar, footer etc everytime.
1) You could send the sidebar, footer etc as json, and the content as html. [edit: an by json I mean javascript ;-) or a combination of a script-tag with a fancy-nav.js, and then pull in any additional elements via json/javascript urls]
2) "lot of bandwidth" - I doubt it. It's only the embedded html you'd have to resend -- and that gets compressed with the rest of the main html document. Everything else (images, css, javascript) gets cached via normal request caching.
