Yeah. And again, in fairness, I suppose it's counterintuitive how much energy is stored by a gallon of fuel, unless you have already been surprised by it in the past :) But even comparing to batteries, you have to stationary-bicycle for a long time to make the energy to charge even a single 18650. Hydrocarbon fuels are the rocketship that fueled the 20th century's insane industrialization (on top of their use as fertilizers, feedstock, etc) and things would look very different if we were still cranking the washing machine by hand, so to speak.

But I also agree with your point on the importance of "napkin math", understanding the relative order-of-magnitude of effects and being able to do some rough estimates on the spot, etc. I had some teachers who were big on doing this and I hear it's a fairly frequent interview question as well (often in the form of things like "how many ping-pong balls can you fit into a sedan").

Whole-systems thinking is another tough one, and unfortunately it's full of confounding effects that make this extremely difficult. Improving efficiency in one area but requiring a supply of physically-delivered goods is often not really a win in total. Another place this came up recently was discussion about the UA Flight 232 was that the FAA knows that having kids riding on lap in airplanes isn't ideal, but they allow it because the alternative (making people pay for a seat for children) would increase the number of car trips, which likely substantially increases the total death toll etc due to higher risk-per-mile.

Gotta be careful about "pushing the problem around", and that's an engineering lesson too. Making the application 10x faster but blowing up the DB is much worse - we can scale out to more containers if we need, but scaling the DB is hard. So even a "higher-efficiency system" (serialize JSON in C vs in java) might perform worse once it hits the wall. You haven't solved the problem, you've just pushed it around, and this is a worse place for a problem.