Maintaining an open TCP/IP or even UDP/IP network socket to receive incoming notification messages requires sending a packet back and forth every so often to confirm the socket is live and keep it open, even while the socket is idle and there are no notifications.
You can technically open a socket without doing this, and this does work on parts of the internet. It often works between devices on your LAN. But many modern networks have unreliable connectivity, handovers between base stations (i.e. mobile or wifi), often one or more layers of NAT and/or firewalls, and more. The only generally reliable solution to get real-time inbound notifications to a device, is for the device to open an outbound socket and the protocol to send a packet occasioally in each direction. The packets confirm liveness to the receiving endpoint, as well as telling other parts of the network the socket is still live.
When your device hasn't received a confirmation after a configurable timeout, it's time to open a new socket from the device, because the original socket may have stopped working. The timeout lower bound depends on how much delay in notifications you can tolerate due to a non-working socket, and the upper bound is whatever keeps it working through all NATs and firewalls in the network, reduced by a margin to cover latency variance at an acceptable probability of disconnction. Often the packets are implemented as a "ping" request-reply pair in the protocol, but actually there are other, more efficient patterns, and pings are not required at all during periods of other active traffic.
Those pings wake the radio in the mobile device, which drains the battery more than you'd think.
If you have 50 apps each using their own separate socket and background process, they will wake the radio up to 50 times more often as one app, assuming they have independent timing.
If the 50 apps are synchronised to communicate at about the same time, they will wake the radio less often to send and receive packets for multiple applictions in a single radio wakeup. By itself this saves battery power, because the device's radio is able to send multiple packets with only a little more power consumption than a single packet, if they are within the same time slot. This also reduces radio overhead on the mobile network due to how time slots are negotiated among devices.
However, that requires all the apps to use very similar protocols and to synchronise somehow. Even more power is saved by having one shared app (or service), with only one socket open to a shared server. As long as that shared service handles notifications for the other 49 apps, and the 49 app notification channels are idle nearly always, the shared service reduces battery power consumption considerably, as well as reducing IP network traffic and mobile radio overheads.
That's three technical reasons to have a single, centrally managed notification service per device.
Additionally, the device maintains real-time contact with the mobile network. To do this, the mobile network protocol uses something like the above, sending a packet occasionally in each direction. This happens at a lower level than the IP protocol used by apps, but the principle is similar, waking the radio every so often to keep a live channel going.
The mobile protocol is diferent from the internet protocol normal apps use. The mobile protocl is robust enough to carry real-time notifications of calls and SMSes, among other things. It's not perfect, but when the mobile protocol is delayed or fails to deliver, an app using internet protocols (TCP or UDP) on top of the mobile protocol won't do any better.
If the mobile carrier/network supports it, the shared app notification service can wait for a special mobile protocol event. Think of it like a magic SMS. This notification event comes "for free", as it uses the radio activity already being done efficietly by the mobile protocol, instead of an internet socket with ping packets and its own, separate background radio activity. But this method requires a special arrangment with each mobile carrier, and functionality in the device OS. It's not as simple as the network-independent internet sockets which normal apps use.
That's a fourth technical reason to have a single, special notification service.