Certainly I'd prefer if popular Linux distributions made more versions of tools like Ruby available as packages, but just having Ruby 2.0 and 2.1 installed at the same time is not the only point.
Honestly, the rbenv model is looking pretty good these days given that there's also pyenv, nodenv, and plenv, all direct forks of rbenv. For the servers I take care of, I set up system-wide rbenv and pyenv installs as a non-root user to give our applications the flexibility of these tools without having to screw around with root access where it's unnecessary. It works great, and I'm planning to move Perl to the same model.
What Perl tools will you use to do that?
If you would be willing to chat about such issues on the IRC channel #perl6 on freenode (usually busiest from around 8am to 8pm EST), especially with FROGGS and/or lizmat, you could help the Perl 6 team as they specify and implement package management that tackles these issues (multiple compiler versions, multiple module versions, alternative implementations by different authors, CPAN/PAUSE, github, local repos, and so on).
rbenv basically just chooses which ruby (along with the gems that are installed with it) is active on your system.
rvm also provides a gemset functionality that is more like the virtualenv model, where you can have multiple gemsets per version of the interpreter.
What virtualenv doesn't handle as well as either of them is choosing between installed versions of python. What virtualenv does better than both is create an isolated environment for your python program.
* And even then, you don't set the default ruby for the entire system, you set it for your own sessions.
For interpreted languages, I don't know why we can't just do something like:
Languages in general would be better off designed around having an executable that bootstraps loading the version appropriate for the code you are trying to execute. i.e. the `ruby` executable shouldn't be versioned, but instead be designed to to determine the version of ruby you need and then execute your code using that version. The obvious way is to have user's specify the version they need, but there is nothing stopping someone from creating a tool from each language that does nothing more than trying to parse the AST for a language and searching for tokens and language features that identify that code as being executable with version X, Y or Z. Furthermore, the language could easily keep a key-value db on disk whose sole responsibility is keeping keys that are the absolute path of the file on disk and the values are the mtime and sha256 of the file and the version of the language with which to execute that file when not explicitly stated in the file or program manifest.
For everyone else, do your development in a VM that matches prod. Use distro packaged Ruby.