While Google is the main implementer of RCS servers and clients, a few larger carriers have done their own implementation of it, with no need for Google.
Client side, I believe Samsung had their own implementation for it? And Apple could make iMessage RCS compatible, they just have chosen not to at this point.
Edit: to add, RCS does support 1:1 encryption now, though I don't believe it's fully rolled out yet. https://www.theverge.com/2020/11/19/21574451/android-rcs-enc.... I'm really hoping this is the last step to get Apple on board with implementing it.
And that's why I think RCS shoot itself into the foot.
I understand that Google does want to accelerate RCS implementation, and some carriers have actively chose to use Jibe.
The main problem I think is that RCS is not differentiated from SMS, especially for those who have a carrier which didn't deployed it yet. In well-developed areas, it make full sense not to differentiate it. However, I don't think (and have some anecdotal evidence) that RCS was not designed to handle the (relatively) common case of an RCS user sending RCS to an "RCS" contact while that contact is offline. In certain areas, data connectivity is not cheap which means that the user explicitly controls mobile data connectivity and Google is amplifying the problem by actively prompting the user to use RCS even when the carrier does not support it. This leads into important messages not being received, which makes sense if RCS replaced another IP-based communication protocol but SMS is circuit-switched and does not rely on IP infrastructure, and more importantly SMS is much, much reliable relative to RCS (especially if it is not officially supported by the carrier).
I need to point out that I do not really disagree with RCS' intent - but Google aggressively trying to promote RCS outside of commited carriers is not just weird but can be dangerous.
Having RCS is still better than being in current situation where you're locked into Whatsapp/iMessage/Some proprietary solution from a carrier