It's a trade-off. If the device is not able to receive the notification at the time it was sent out, it has to be stored somewhere, pending delivery. It's the

It's a trade-off. If the device is not able to receive the notification at the time it was sent out, it has to be stored somewhere, pending delivery. It's the same with email, SMS, literally every messenger app, heck it's the same with physical parcels! You could argue the protocol should allow the sender to store the message, to allow the receiver to fetch it directly, without a middleman - and this is more or less what RSS is, except the polling architecture causes both extra latency and increased server load. But we could "fix" RSS by eliminating polling, etc - that's an easy engineering problem, the true issue would be standards/consensus. Finally, since we're talking mobile devices, you must consider battery usage. It's cheaper to keep only a single TCP connection open; this path is heavily optimized at every layer of the stack, from network hardware and drivers to the app-facing API. Notably, email notifications have to go through their own network path (there's a couple of IMAP extensions to enable push), this is part of the reason why some email apps would like to look at your email from the POV of their own hosted backend. These choices reflect the fundamental problems of mobile messaging. But we could still improve upon the status quo - like requiring E2EE for notification payload. That would be a huge effort though, as an app vendor you already need to implement APNS/FCM/Web (all very different from one another), and I'm sure every middleman would like to build their encryption slightly differently. Adoption would be slow and painful.