The difference isn't between sending a couple of extra packets versus rendering on the client. It's between rendering on the server PLUS sending a couple of extra packets versus rendering on the client. You have to do the rendering somewhere. Assuming the code that does the rendering is essentially the same whether it's server-side or client-side, the only difference is sending the extra structural layout data when you render on the server. For most sites it'll make no real difference but if you're at Facebook scale I'd guess a couple of extra packets really adds up, especially considering you could cache the client-side templates between sessions.
So I imagined it as 1 render vs potentially thousands.
Another thing to note: You'd (probably) have to try real hard to find a server side templating solution that would render as slowly and use as much CPU as JavaScript on the client-side.
Rendering public, read-only content such as a tweet, however, makes total sense to cache on the server.
Facebook probably requires a lot of per-user effort true. A lot of sites (github for example) probably don't. It's probably limited to a couple areas of the header generally, or an A or B conditional render for an ownership page.
There's always exceptions to every rule though.
It's just intuition on my part, but I think the environmentally friendly option is probably actually sending a couple extra packets (server-side rendering) vs cooking the CPUs of however many clients you have with JS (client-side rendering).
Also, never experienced an application where parsing a blob of JSON and manipulating the innerText and values of HTMLElements with JavaScript was more efficient than setting innerHTML.