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.
Not sure I'd agree with over-engineered, but anyway.
End-to-end privacy with multi-device support has been specified in XMPP for years; the problem is that it's vastly complicated and therefore nobody ever implemented it.
In part this is because when XMPP was started, people wanted different things from multi-device - they wanted to be able to leave their desktop logged in, move to their laptop, and not have the conversation pop up there - there being no message-read state in XMPP. So instead, the idea was that you'd pull the archive from the server if you wanted it.
Later, Carbons were introduced, which basically says that if the message wouldn't normally come to "this" client, tell me about it anyway.
As for end-to-end... Well, the original RFCs include a method based on X.509 and CMS (RFC 3923). Never implemented. There's been various different concepts since (OTR-esque and XMLSEC based). None has yet got traction, but you'd be welcome to draw a line in the sand and implement one of them.
The only thing Google actually did fro mobile XMPP was google:queue, which bunches together presence updates such that the antenna efficiency is improved dramatically.
Facebook also have a private extension, as I understand things.
I should actually submit that extension - I wrote it up as a XEP ages back, but various things have held it up.
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.