> They do it so they don't have to stand up their own push servers

I don't agree with this dependency on being in good standing with Google either.

But there is a technical reason that isn't wanting to avoid using their push servers. It is about battery usage and radio bandwidth.

Keeping open an idle connection over WebSocket, long-poll HTTP or TCP/IP needs regular pings (typically 30 seconds are used), one ping per connection. Otherwise your app can't be sure to receive messages from the server in real time, as the connection can disappear into CGNAT or similar hole where it doesn't receive messages sent by the server. To an app not using pings to check, such a blackholed connection is indisinguishable from an idle connection with no pending messages.

Waking the radio every 30 seconds, times 2 (back and forth), times the number of registered applications, would be quite battery draining. It drains battery both for background CPU usage and radio processing. Those pings in aggregate can even amount to a significant amount of data usage for users on smaller plans.

So there is a battery and radio advantage in using a shared push service, which only need a single idle connection to be kept live with 30 second pings.

There's another level to this, not available to regular developers using TCP/IP, HTTP or WebSockets.

The mobile network itself has to maintain handset connection liveness to the nearest tower, at a lower level than IP pings, and this is obviously optimised for battery and radio performance, and always running.

With arrangements in place with the mobile networks (which Google and Apple have), the mobile OS can leverage that for more reliable, lower power push notifications, by either guaranteeing the network will send something technically similar to a low-level SMS when there's an outstanding message, or by guaranteeing their special push IP connection will stay live by itself (no CGNAT blackhole) or be notified if something happens to it.

This allows the mobile OS to offer a shared push service that's fairly reliable at real-time notifications, with zero continuous CPU and radio power overhead for the idle connection.