Nothing at all; this was a decision made by the Hangouts team. The XMPP change has to do with the NIH syndrome a lot of Google engineers suffer from, combined with the incompetence of the Hangouts PM, Kate Cushing.
It is my understanding that XMPP also presents a problem with regards to mobile due to inefficient design from a power usage point of view. I could certainly see how that would be reason to look into fixing or outright replacing XMPP but not opening the replacement protocol is just shameful.
They are still supporting XMPP for c2s connections, though; i.e. if you are on a phone, you can use XMPP to connect to Google. What they don’t support is s2s, which – unless you somehow run your own XMPP server on your phone – has nothing whatsoever to do with mobile :)
FWIW, they could “easily” build a mobile client that connects to Google via some nonstandard protocol which preserves energy on the phone while being mapped to the standard XMPP protocol from Google onwards.
Funnily enough, that's exactly what they did do, back in 2008 :)
Originally Android included an XMPP API that applications could use to connect to Google and other XMPP services. This got replaced by a Google Talk-specific API at the same time they switched to a proprietary protocol.
Naive implementations of XMPP on mobile can indeed get quite power hungry, but it doesn't have to be that way. Thankfully I've seen quite a bit of interest lately from mobile clients who wish to improve on this - all the resources are out there.
XEP-0198 is currently gaining adoption quite nicely for example, it allows for reliable streams (resume them without message loss or the need to re-sync everything if you get disconnected).
Yes, XMPP is power inefficent as the server can send presence notifications at anytime to the client even though the mobile user is probably not interested in notifications about who of his 200 contacts just went away or came back. Unless he looks at the roster.
BUT this can be solved easily, when you control the server and the client. And this was already solved by google for years with gtalk. So this is not an excuse to stop federation.
I don't think XMPP is necessarily power-inefficient.
Every Android device with the Google services installed actually has an XMPP connection open the whole time (albeit with some protocol changes); it's how push notifications work on Android.
But google invented Jingle, and in the XMPP space I can't imagine they didn't have a dominate authority. And you can add whatever extensions you want to XMPP, standard or not.
Google did start Jingle and large part of their work ended up in the Jingle standards at the XMPP Standards Foundation. However, Google Talk and the old Hangouts took quite a while to move to the standardized version, and were never fully compliant. Also, in other areas, Google never quite interacted with the community and left major issues unresolved.
Basically all of the issues, perceived flaws or missing features attributed to XMPP in the old implementation of Hangouts were either misinformed or have seen development or new specifications in the XSF. Google never contributed to such discussions, with the exception of individual Googlers helping with Domain Name Associations (DNA, http://tools.ietf.org/html/draft-ietf-xmpp-dna-05).
So far as I can see, the Hangouts implementation still uses XMPP, and even sends some federated messages to other servers. It looks like there has been some kind of code added to specifically block the functionality for which code already exists.
Disclaimer: I work for Google.