What I really like about XMPP is that I can do precisely this. Also, setting up and running prosody is dirt simple if you have any UNIX experience. IMO it's even simpler than running your own web server.
Not understandably at all, the reason for the lockdown is not for your benefit even if it is portrayed as such. Push notification can be run just like SMTP and is subject to the same type of abuse with the big difference that it actually easier to keep the spammers out since you know up front which senders are allowed to send notifications. It would be fully possible to self-host a push notification daemon which connects to those services which are meant to send you notifications, to which your devices connect for notifications. If you don't want to self-host it would be possible to choose a notification service just like you can choose an email provider. Things could be just as hands-off as they are now without being forced to open an Apple/Google/Microsoft account and hand over your communications to them.
Don't be fooled by these 'for your protection' lockdowns, they are for the benefit of the one doing the lockdown, not for your own.
And tbh I'm not sure SMTP serves as all that positive of an example. It works, sure, but the reputation system and extreme complexity that has sprung up around it makes it difficult for newcomers to join - I can't just host one from my house, most email hosts will reject my emails. It works in spite of all this because it has too many large actors already using it for any new ones to stand any chance of rejecting (or improving) it.
If there was, it wouldn't take much to make an XMPP extension or three for the client to provide a push url to the server. Client devs would (probably) need to standup a push proxy, so xmpp server pushes to client server pushes to client, because I don't think many platforms give out push urls that can be securely passed on to 3rd parties. There's some expense there, but not a whole lot, IMHO.
While it's been an awfully long time now, I seem to remember that services like AIM didn't successfully move to mobile because they required stateful connections similar to telnet/SSH, and that was something that just wasn't (and largely still isn't) possible under iOS.
Google had an xmpp system (google talk) for which they have a first-party app which they send push notifications to. No other xmpp app can take advantage of that for google accounts - they all need to run, essentially, an xmpp-bouncer + their own push notification infrastructure and client implementation.
In ye olden days, a google-free version for google-free xmpp accounts could not be built in many cases, as the mobile device's APIs wouldn't let you hold open connections in the background like that - that was unique to the platform-owner (Android / iOS). Now you basically can, but each implementation increases battery use, so there's a fair bit of pressure to use the built-in one instead... which you can't do, Google won't send your app any push notifications that are intended for their apps.
---
The same thing applies to email apps, for example. IDLE just plain doesn't work well enough on phones, so email apps build their own email backends so they can use google's push notification infrastructure to push notifications for google-owned email account events. Google is the first party here, owning the email account and infrastructure, but not sending notifications to other email applications.
And also for basically any third-party app for basically any service. E.g. Talon (a third party twitter app) has to resort to polling Twitter's API to do anything. But those at least aren't federated systems, so though I'm still a bit sad about that, it's much more understandable that it happens.
AIM is a lot like AIM, and it worked fine on BlackBerries.
yep, that's the downside of xmpp, isn't it? How could that be mitigated?
Still, battery is important to consider, so what have we done in XMPP to improve energy efficiency in the past 15 years?
One of the first things we did was define a way for clients to reconnect a session that suffered a broken connection - the classic "I just went through a tunnel" scenario. With this optimization we gained two things: a way to quickly reconnect without resynchronizing everything, and a guarantee that no traffic was lost in the process due to the network interruption.
Secondly, we've implemented traffic optimization in servers. Clients will tell the server when they are idling in the background, and the server will stop sending any traffic that isn't time-sensitive. As soon as the user focuses the app, it tells the server and the connection switches back to "real-time" delivery. This behaviour helps keep network activity low when the client is in the background, and prevents continuously waking up the device's radio (such wake-ups can be quite power hungry over the course of a day).
Finally, modern mobile XMPP clients support push notifications, which is the Apple/Google sanctioned way of solving this problem. It means that you can safely close the XMPP client entirely and still get notified when you receive messages.
There's probably more besides these things that I've forgotten but I think these changes are the highlights!
Sending push notifications, which is broadly necessary for achieving both performance and battery efficiency, has been strictly centralized and locked down (understandably, I'd hate to try to block abuse if I were running it). Federated systems with multiple apps were pushed out because there was no sane way to achieve that with the push architecture, and that's still the case. You see the same thing with nearly any third-party app, they're nearly always partly-crippled experiences because the first-party will not send push notifications to anything but their own app.