Yet that's what I believe it does. Every few seconds, Nest sends an HTTP POST to their servers with its serial number. If there are any commands waiting for that thermostat (change temperature initiated from an app for example), they get sent in response, otherwise the connection is closed.
That's the client pulling, not the server pushing. Pushing would be "when the owner makes a change on the website, notify the appropriate thermostat to change its settings". This would be way more efficient, but too many Nests aren't going to have suitable internet connections.
Perhaps you misread "yet" as "yes". I'm curious if there's a power issue as well. I don't know how fast wifi can turn on/off and reconnect to a network. Nest has to be low-power as its only power source is one of the tiny wires from the HVAC system and that doesn't supply enough to run the device offline, let alone online. It uses that wire to charge an internal battery instead.
That sounds a bit hyperbolic. I think you're overreacting. The difference between this and long-polling in terms of hardware required is pretty minimal. I run a web stats service that has to deal with similar kinds of data -- millions of sites "pinging" it with a new page view to record constantly -- with one crappy server. Nest doesn't even have to record anything in response to those pings, unlike my server, just compare to some in-memory table of which devices have commands waiting for them, so most connections can be immediately disposed of.
Given the setup, network and power requirements Nest operates under, this may well be the most efficient way it can be done. Or maybe it does do some kind of long-polling and the descriptions online are inaccurate. Either way, I doubt there's anything "absurdly wasteful" going on here. Poll vs push isn't melting polar ice caps.
Nope; if you have a device in people's houses you basically have to configure them to pull. NATs and other connectivity tricks mean they can reliably initiate communication with you but not the other way around.
I'm intimately familiar with the relevant issues. That the client initiates the connection does not make it "pull", you're confusing distinct issues. Push is almost always implemented with long-lived connections initiated by the client side which remain idle save for periodic keepalives until there is actual data to transmit.
