You manage feature differences one way or another. If you like choosing rbenv vs rvm vs asdf and then using them to manage your ruby versions and gem dependencies rather than having in-band switches in a single interpreter, great, you're welcome. I could even see someone making a case that it fits neatly within an org where systems/devops folks take more of the environments/dependencies division of labor.
If what you really like though is the charge you get out of just saying "this is dumb" while indulging the privilege to not even notice that you did a repeat performance of unsupported shoulds vs worthwhile tradeoffs, though, well, maybe you should examine that.
I use the system Ruby and don't have to worry too much about rbenv and rvm. 2.7 and even 3.0 is well supported. That's what I also did with Perl, except when I used MacOS which was a pain because of modules that used C libraries like LibXML. On Linux we can also use containers without worrying about speed penalty. There are sufficient solutions and okay tooling. Ruby's also got not one but two JIT compilers right now.
If what you really like though is the charge you get out of just saying "this is dumb" while indulging the privilege to not even notice that you did a repeat performance of unsupported shoulds vs worthwhile tradeoffs, though, well, maybe you should examine that.