This is the reason why I went out of my way to use Molly (a fork of Signal), since it supports delivering the push notifications through a self-hosted server instead. Unfortunately the process is complex: it requires both a method to deliver the notifications to your phone via UnifiedPush (an alternative to Google's push system that generally suffices on its own) and a compatibility service called MollySocket (that bridges Signal's notifications with the UnifiedPush provider). Both typically need a self-hosted server and specific configuration to talk to each other though. And I don't even have any contacts that use Signal anymore, so, well...!

That is correct.

However, this is a quasi-monopoly by google having quietly overwhelmed the space. Same thing for RCS messaging.

Neither push notifications nor RCS are proprietary, so there is a possibility to tear oneself from google here.

For instance, there are several free and paid push notifications services. Pushbullet is a popular paid one, not too expensive. I personally use https://ntfy.sh/, which can be self-hosted.

RCS is different because trusting the encryption keys makes RCS work, so there would have to be a critical mass of buy-in to use an alternative to google's RCS implementation.

From what I recall, Google would be able to see our device received a notification and when but not the actual message nor sender/recipient identity.

I think that's fine for my threat model.

Molly seems like a potential alternative though since its a signal fork and supports UnifiedPush so you can choose a different notification supplier like ntfy or sunup

you can choose websocket on signal instead of Google unified push