Interesting as the old backend was p2p, but it sounds like hangouts are a more standard client/server. Maybe Google needed more voice data to mine. Actually better yet, facial expression data to mine. After all, Glass could live and die by its ability to correctly identify faces.
http://support.google.com/plus/bin/answer.py?hl=en&answe...
In a P2P video chat setup, each client has to send its video to every other client; if there are 5 clients, and the minimum outbound is 230kb/s, the client has to be able to push 1150kb/s (9.2mbit!) upstream, which is present almost nowhere in residential broadband.
Based on the downstream requirements, it looks like Google is also doing some kind of stream multiplexing before sending the hangout to clients, which reduces the downstream requirements, as well. In a P2P situation, you wouldn't get that benefit.
Even if you go with an "elected master" setup, where the biggest-bandwidth participant is responsible for stream multiplexing and broadcast, then you're disproportionally punishing that user and potentially degrading their user experience by burning a ton of CPU on the multiplexing, and the other clients are subject to their latency to the master node.
Running this through their infrastructure makes a ton of sense without the tinfoil hats.