This is clearly nonsense. There is no evidence that Android phones "hog data", it's also quite clear that Android phones are not all plastic and function far better than you seem to understand.
Actually, there is. If you know about how and why the iOS push notification system is designed the way it is, and understand that Cloud-to-Device (made available on Froyo) implements the same thing, you'll know why. It's the flip side of why do-as-you-wish multitasking on Android isn't all fun and games as people make it sound.
The basic summary is that prior to 2.2, the only way for an app to receive background notifications was to write their own background process that communicates with whatever server the service needs. The process would run in the background and poll through the data connection.
Since most developers straight up suck at implementing efficient persistent network connections, most of the daemons would start and stop the network interface as they please to contact their server. So the phone's radio would turn on, connect to the network, initiate a TCP connection to a server, and then tear it down every x number of minutes. That overhead of starting up the connection and tearing it down is practically half the data transferred when doing a simple poll. (if the poll was larger, then that developer is even more of a moron.)
Now, that's one app. What if say I had 2 apps on a Eclair phone which polled. One at a rate of 5 minutes, one at a rate of say 15 minutes. What if they didn't start and stop at the exact same time? Say 1 minute apart?
At 0 minute: App A uses the network.
At 1 minute: App B uses the network.
At 5 minutes: App A uses the network.
At 10: A.
At 15: A.
At 16: B.
... and so on.
The time it takes to bring up a data connection and connect with the network is about 2 seconds. Likewise, taking it down is about 1 second. The phones don't do this bring up/teardown within every second though. It's actually like over a minute or two in order to make sure that while you're reading the page and about to click something, it doesn't cost them another 3 seconds. So once it's started up, it might wait for about a minute or two...
Which means, in that example, the radio stays up in between 1 and 5 for another minute. 16-20 for another minute.
What about a third app? That could overlap. Or it could make things worse.
Pretty soon, with just 4 apps, your radio might be operating half the time your phone is sitting in your pocket. How easy is it make it to 4 apps? Gmail, Whatsapp, Facebook, GoogleVoice. Done.
Of course this is an example since timeout, network connection time, and all that can vary from model to model and carrier to carrier. But it's there in general.
So that situation was pretty much guaranteed prior to Android 2.2. In Android 2.2, Google copied Apple's push notification backend design and provide that as a service. The problem is, if the developer of the apps don't switch to using it, they'll still do the lame stuff they did in older Android phones.
What's so good about APNS and Cloud-to-Device?
Simple, it reduces overhead (less data sent), reduces the amount of time the network connection needs to be on (less battery life used, less time spent on the network to accomplish same goal), and less work for the developer since they don't need to learn about how to make their own background notification system.
How does it work?
Apps who need to get notifications connect to a server. The server gathers all of these together. The phone has one service designed to connect with the notification server whenever possible. Instead of starting up a TCP connection, it can send UDP which is less data sent.
Instead of everybody polling whenever they want to, the phone's service will coordinate when the poll so that all of the apps get their data in one go.
When the phone is already online, the phone side of things knows that it's not a problem to poll sooner.
When the phone is idle, it can slow down polls to save battery power.
Combined together, it just ends up being better for everybody.... as long as people use it.
Apple forced developers to use this through the lack of other options and the App Store approval process. This is good.
Google implemented this late, and has no way of encouraging its use. Heck, even in Google's own Android apps, it seems questionable that all of them are using it as well.
At any rate, this goes to show you one of the reasons that iPhones use less network data than Android and get better battery life, while trying to accomplish the exact same thing.