Does anyone know why, if I can bypass it?
The reason is, that you won't get battery savings if random app can keep your radio busy. Since mobile carriers managed to kill WAP-Push some 15+ years ago, the only way to get push notifcations is to have a long-lived TCP connection open.
However, that opens another can of worms, there are multitude of timeouts on the way between your phone (including your phone) and the push messages server. Most apps would get this wrong, and they would have to cooperate together anyway (radio is global resource on your phone, it won't switch to low power if another app is busy chatting).
So on Android phones that come with Google apps, the task of managing push notifications is handled by Google Play framework (and also whatever Amazon is using), by single long-lived connection, used for all push messages, and not by apps themselves.
Anybody remember the way Blackberry handled this before proper push messaging? The data connection was completely dead, they just got the mobile companies themselves to do it over the phone call connection (SMS?) to indicate when there was something to read at which point the data layer came up. Really efficient in those days, except you obviously paid a fee for 'Blackberry service'
From the privacy aspect, I believe all notifications are end to end encrypted actually. Same as Apple.
I would actually be interested in being able to choose the server used for this service, and would enable it without hesitation if I could use my own server for instance.
Your phone has a persistent connection to it so that the GCM can "notify" your device when you receive a push.
The alternative is to have a custom Android OS linked to your own push provider and then convincing app server developers to send pushes to that instead.
Unfortunately, whether we like it or not, it's hard to get away from.