And here I am, hosting a Matrix server for my family for 6 years now, with no issues and an amazing experience, from the backend to the huge variety of mobile clients, a mature Rust sdk that I can hook bots into with ease, etc.
This protocol is XMPP in 99% of the time, both Apple and Google use XMPP to connect the phones to their push notification service.
On Android, some Matrix clients offer the option to use non-Google push notification channel via UnifiedPush. UnifiedPush needs a distributor, a service that runs on the phone and manages the delivery of push notifications. Conversations, a popular Android XMPP messenger, can be used as such distributor.
So if you want digital independence with Matrix and thus do not want to use Apple/Google push, you might end up installing an XMPP messenger, so that your Matrix messenger actually can show notifications. Matrix alone just doesn't provide what is needed for digital independence.
(aside long polling which I cannot comment) why is this a even an issue?
Centralized push services (may it be FCM or unified push) are at this point well established.
As a user using a specific messenger app as a push service doesn't gain me anything, it only makes it more difficult to switch messenger app if i choose to use it and mostly use an additional push service (hurting battery life), because most receive push notifications via Google anyway.
I think the right solution is to use a different notification service, not controlled by Google or Apple, not to get rid of the concept altogether.
XMPP uses a persistent connection. These are kept alive using TCP keepalive (both from server and on the client, but client side will be handled by the MPU and thus doesn't need CPU wake-up) and client initiated application protocol pings at intervals of 5 minutes or even less. Client initiated pings are much better on the application protocol, because they can be synced with other operating system tasks and thus don't need any active wake-up.