Bandwidth used means radio transmissions sent, and overhead means more work done by the processor, both of which take battery power and reduce battery life. Meanwhile, compression turned out to not be very helpful. Since it's negotiated during connection startup, it doesn't help with startup overhead. It does help somewhat with steady-state bandwidth, but at the expense of additional CPU cycles. The result is that enabling compression actually reduced battery life in our tests -- it took more power for the CPU to do compression than we saved on radio power.(I wonder though: perhaps they could've used a simpler form of compression? XML ought to be "easy" to compress. Maybe the spec doesn't allow it?)
You see a similar phenomenon with HTTP on a heavy page. Like CNN.com: Firebug says it took 135 HTTP requests to load the page. Many of them are to a CDN and only have ~400 bytes of request headers but all the ones to cnn.com (including the ads, apparently!) include cookies pushing them up to nearly a kilobyte. The net result is that the latency of the page starts getting affected by the end-user's upstream bandwidth, which is usually terrible. (But now, having typed that out, I wonder: does it really matter? Even those heavier requests fit within a packet anyway...)