With current notched phones which are limited to 4 notifications (you get four and a dot if there are more), you can have VPN app, XMPP client, Syncthing, and a generous space for one more incoming notification.
Those tools existed and they didn't help because users had no recurse against poorly behaving apps. Meanwhile Android kept being reamed by reviewers and media for poor battery life and people kept buying locked-down iPhones instead because they lasted longer.
I spent countless of hours trying to get Android devs to not do dumbass things with battery ("oh, I need updates? I''ll just poll the server every 20 minutes and ruin the users battery in hours. Easier than long polling!") and in the end the situation didn't improve until Google stepped on the devs neck and forced them to use GCM/FCM and started actively powering down radio without apps input.
Users have very effective recurse against poorly behaving apps: uninstall. You just need to inform users that the app X does use much battery. Then it should be up to the users to decide if to allow this behaviour or uninstall this app. Maybe an explicit permission to run in the background. That's it.
Solution that you like is also very beneficial for OS vendor, how convenient.
In your reasoning, "most" users would be done and "most" apps would be malicious.
But in the end, it's quite simple - dealing with power use on mobile is hard and most developers don't care (same as they don't give a crap about making your web pages fast and slim). Users care about battery life above most of other features, including your freedom. They WILL got and buy a device that lasts the longer amount of time in the smallest and lightest package.
As long as these two things are true, leaving developers to run their polling code without restrictions has a massive effect on sales of both OEM devices and Android ecosystem as a whole. As such, OEMs are actively modifying Android to not allow this - see the wonderfully depressing https://dontkillmyapp.com/ - which is a significantly worse mess than you having to use a proprietary service to send a single device wakeup ping.
Even correctly behaving apps will consume much more power and network with this scheme.
I was an Android dev pre-5.0 and believe me, having lived through the s*tshow that was push notifications at the time, there's no way it would've worked any other way. Google's own SDKs were garbage and as with everything else they kept releasing new incompatible rebranded versions annually. Last I checked, the Firebase console for managing push notification subscriptions was still one of the worst SPAs I've come across.
You'd expect a thriving ecosystem of dedicated push notification providers to pop up and outcompete Google, but all of the 3rd party offerings were even worse, in terms of battery life, UX, reliability and even pricing.
It's unfortunate, but no developer cares about your battery life, because no user is going to switch away from using their app solely because of crappy power usage, so Google had to do exactly what they did.
Maybe in a decade or two, with new battery technologies, there won't be a physical limitation and this situation would play out differently.
I was in Android dev since pre 2.0, developing an app which need to constantly run. The situation got worse since then, not better.
A thriving ecosystem of dedicated push notifications can't pop up because you can't go to Android settings and choose another push notifications provider. You have to rely on ugly crutches to even receive a push notification, and that is why they are 'even worse'.
So you either need every app developer to maintain the list of all push providers or someone, presumably Google, to maintain the canonical list and the thing that manages sending them to all the push providers.
Oh and then there's the associated suite of privacy issues. Do you really want every push notification prouder to get even metadata about all of your push notifications?
So this can't be a global setting. Instead it has to be a per-app setting where like the app provider needs to register a callback to update the notification server and support that in app. Of course most won't.
