Well, yeah, if you are very optimistic and generous. In reality, this is yet another way of the manufacturers maintaining power over their customers' property. After all, there is zero reason why any of those things would require them as a middle-man, they could just invent a protocol for that and/or provide a library and a system service on the device that allow applications to maintain a background connection without the need to involve them in any way on the network/server side. The only useful involvement they could have might be providing endpoints for measuring and exchanging NAT timeout information for providers, maybe.

But in any case, none of that is an argument for building a protocol that forces the problems that result from that on all platforms that don't have such restrictions, at best that is an argument in favor of workarounds to make things work as well as possible on such platforms.

Also, I would think that the long-term solution to this problem should be mobile link layer protocols that allow the mobile station to receive incoming packets with little delay while still conserving power. Stuff like high-powered, high SNR alert channels that allow the mobile station to shut down everything apart from a simple, low power, receiver, that only powers on for a few microseconds every few hundred milliseconds to listen for a wakeup signal from the network, so that incoming packets can be delivered with a latency of a few hundred milliseconds at any time. And then you are stuck with a stupid poll-based protocol that's adapted to the limitations of some ancient technology as a replacement for an even more ancient protocol that didn't have that limitation.