OS makers could install a default UnifiedPush distributor though.
Lastly, the Embedded FCM UnifiedPush library (to be embeded into a client app) handles UnifiedPush over FCM (Google-provided push notifications), so that a server only has to handle the UnifiedPush API (with a rewrite proxy for UP->FCM).
What's the actual likely hood that the average end user is going to install a random service?
For now, UnifiedPush is targeted towards De-Googlers, self-hosters and FOSS enthusiasts, not average users.
Which implies the use case people are seeing is phone apps. Unless people are building one off apps for themselves, you've got end users in the mix.
I don't see how this can be positions as much outside of phone apps, as txt messages or emails would be easier and more universal. Being that they're probably going to be supported here.
To note, i haven't see anyone talking about this being replacement for the part of webpush that handles registration for notifications or whatnot, but as a whole separate channel/technology. Not 'install this to avoid using google/apple for webpush' but 'use this in your app, and have your users install the service'.
So yeah, the app has to support it, but the user can choose then.
That's pretty much it. Because there isn't really any possible alternative except something that looks like this.
GCM/APNS/ETC do not fit those requirements, so it needs to be something new.