The problem is mobile, and specifically the need for push notifications to have reasonable battery life. The traditional model that desktop IM clients use, where they have a permanent connection to the server, is not viable on mobile. But push notifications require you to design your protocol around them and lock you into the corresponding provider (i.e. Google or Apple, depending on the platform).
I'm not familiar with real world home firewall behavior, but shouldn't you be able to leave a TCP connection open/idle with no keepalive for minutes if not hours? I'm skeptical of the battery life argument around notification lockin, particularly when I see how much Android devices light up a pihole.
I don't claim to understand the specifics, but I was a heavy user of custom XMPP clients on early Android phones, and they did require a persistent notification to keep the app (and thus the connection) alive, which did translate to measurable battery impact. My understanding is that the built-in notification manager helps with this by multiplexing and batching everything.
