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.
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.