The issue for mobile is that unrestricted push notifications are a serious battery drain. I think that JMAP makes the correct choice here, a push notification is just an external action/url, how the notification is delivered to the human is left out of the protocol. I would say that it allows for both openness and centralization without a bias for one or the other.
My understanding is that a important property is that the device does not receive network packets that are not "replies". So that it has control on when it is fine to power down the network (in a very gross simplification)
So maybe something like what you are describing would be a protocol where the client can say "pin me back with this for this category of events but no sooner than X minutes", but at a network level, like a tagged TCP sleep function.
I never thought of this possibility. In the form I have imagined it it is technically inferior, but it would be an interesting approach to decentralization and surely could be improved.
I will argue that if you use the right data structures--not that anyone does--it really isn't that hard to make that work on the server, and the benefits to the client are actually enormous... particularly on mobile!
The way IMAP handles message identifiers allows for the client to pretend to manage a ridiculously large list of messages without storing any state locally that isn't visible on the screen (like it is _so good at this_ as Mark Crispin seriously intended the original IMAP protocol to be used by thin clients for mail: synchronizing mail over IMAP was never the intended usage model), as the entire problem of managing that consistent view has been pushed to the server (where it is solvable, just no one cares enough to even do a basic implementation correct much less a good one as everyone misunderstands and detests IMAP).
FWIW, the argument for how JMAP supports update batching over push notification channels is in fact interesting for mobile clients :(. That is so totally the fault of the mobile networks and OS people, though :(. The correct solution for that is to provide a flow control layer for wireless IP, at which point every app could be doing its own end-to-end encrypted push notification stuff without having to go through Apple/Google, but the incentive structure to centralize notifications through a middleman was just too great :/.