It's definitely not the lack of features, since XMPP is extendable. I've heard that the protocol is quite chatty and would cause power drain on phones. That could probably be solved with a binary serialization alternative to XML, though.
Yeah, there's http://xmpp.org/extensions/xep-0286.html which discusses some ways to mitigate the power issue, but, from what I understand, we never got much feedback from mobile developers about it. In particular there are several extensions which remove the need for a lot of network traffic (capability hashes, roster versioning, stream management to immediately resume a session that got disconnected, etc). The fun part is that 1) a lot of mobile client developers haven't implemented those and 2) most require server support, and Google never added support for them.
While the use of XML in the protocol might be considered verbose, stream-level compression from TLS quite makes up for that. With many contacts, the number of presence stanzas might indeed drain the battery because the antenna will be 'up' quite a bit.
However, the XMPP community has been active in quantifying such issues and providing solutions. The beginning of a document with background information is available as http://xmpp.org/extensions/xep-0286.html. There are also various opinions on the topic to be found online, like http://www.deepdarc.com/2008/02/14/mobile-xmpp/, that, as you can see, dates back half a decade already.
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.
Yes, it is. The very start of a session is usually synchronous (authentication, etc), but after that it is async. Request/response commands have an id value to link the request to the response so it doesn't matter if other data arrives first.
