Most of RCS can be (and has been) implemented by alternative apps, actually. Several carriers have made their own RCS apps for use with their RCS servers, because phones didn’t have support. There are issues (the lack of notification signalling, for one) but they can be worked around. There was a library for this, but it got abandoned years ago and won’t work well with modern RCS users.

What’s keeping most people from developing these apps is that the standard is quite large, and that a phone number can only be registered with one server, which usually means “Google’s server”. Install an RCS app and the Google Messages app breaks, uninstall the app and Google Messages won’t magically have the keys to decrypt your messages or even receive messages in the first place.

People want Google Messages to just expose an API like they did on SMS and MMS because implementing RCS would be a massive pain. There’s some partial support, but only for reading and not for every type of message. If Google’s messenger would just expose an API, everyone could use the normal system API and you wouldn’t run into issues like “after deleting Signal nobody can text me anymore”.

Then there’s the issue that most carriers don’t bother implementing an RCS server, so most RCS users are actually on Google’s server. Authenticating with RCS servers is complex enough, but adding a non-carrier to the mix with its own weird RCS extensions only makes things worse.

Google’s weird protocol extensions are somewhere between “Google doesn’t publish any details” and “basically Signal+MLS packed in a base64 blob”. After implementing RCS, I don’t think implementing encryption would be that much of a challenge, but it would involve some reverse engineering which really shouldn’t be necessary.