Compression doesn't help CPU utilization, which in turn doesn't help battery consumption. In addition, if the protocol is "chatty" (i.e., sends lots of packets even if there isn't any communication going on -- say, when users change their status/presence information, for example) it means waking up the CPU, which in turn means less power efficiency.

Please read that first document and also my remark about SIFT, which basically allows for delaying or dropping presence to cut down on antenna use and battery consumption.

Hmmm... As the author of XEP-0286, I think I ought to chip in a bit.

1) Compression does help keep the transmissions under the FACH threshold on most networks. This more than outweighs the CPU cost.

2) The bulk of the data to be compressed isn't XML, but text.

3) The chattiness of the protocol - ie, transmissions that are not needed at that point in time - will indeed change radio states, but not only did Google tackle this problem privately, but the XSF has also looked at it in detail.

4) Really, the CPU is a non-issue here. It's all about the radio power states. This is likely to be entirely different at the server end, however efficient XML parsers can and do exist to mitigate this, and make it more distributable.