Смысл фреймворка сообщений Play Services не в том, чтобы *просто* не жрать батарейку, — любое другое приложение, будучи правильно написанным, может делать то же, что и GCM. Его смысл в том, чтобы принимать сообщения с минимальными возможными затратами ресурсов. Вместо 20 процессов, читающих из сокета в фоне, в системе будет один такой процесс (ну плюс пара отщепенцев, держащих foreground-уведомления, вроде скайпа).

Прикол в том, что само отображение уведомления в трее не предотвращает сон, — оно нужно только чтобы система не прибила показывающий уведомление процесс. Когда устройство уходит в сон, процессор просто переходит в минимальный режим энергопотребления. При этом приложения продолжают выполнять код (но ооооочень медленно), и с помощью общедоступного API могут вывести девайс из сна (например, в случае прихода сообщения из сети).

Второй трюк здесь в том, чтобы не использовать keep-alive сообщения (ни TCP keeap-alive, ни протокольный PING). Если что-то отправлять или получать по сети, сетевой адаптер не сможет перейти в режим пониженного энергопотребления, и любая выгода от ухода в сон основного процессора будет сведена на нет. GCM просто открывает соединение и изредка проверяет, что какой-нибудь NAT-сервер по дороге его не прибил.

Всё это описано в официальной гугловской документации по снижению энергопотребления, и отдельные приложения, например некоторые почтовые и Jabber-клиенты, успешно используют эту информацию чтобы сидеть в фоне, не сжирая всю батарейку. Естественно, нужно чтобы сервер с тобой кооперировал: не слал всякий мусор и keep-alive в фоне, объединял соседние сообщения, не будил девайс каждые 2 секунды нормальной активностью.