I like rbenv better than RVM and especially better than chruby.
rbenv does not use undefined shell variables. As a result, I can have “set -u” (warn about uses of undefined variables) turned on in my interactive shell sessions and not be seeing diagnostics all the time caused by my Ruby changer. Both RVM and chruby fail in this regard.
chruby, if you turn on its “auto” optional feature so it will pay attention to .ruby-version files, sets a shell trap that makes chruby code run after every command. rbenv does not do this, nor does it hook the cd command, which RVM does.
chruby requires, evidently, a system global installation, which you have to do as superuser a. k. a. God. This creates a security risk. rbenv by contrast, can do everything from an ordinary user account. So can RVM.
I found that it is practical, even without superuser installation, to have a number of user accounts sharing the same collection of Ruby versions (each account using the Ruby it needs), and have the Ruby versions provided by a user account set up for that purpose. This works with rbenv. I don’t know whether RVM could do it.
All in all, among the three, I prefer rbenv.
<rant>Unfortunately I have to work with some systems set up by someone else, which have chruby installed globally and it’s pretty hard to get away from once it is there and in use by a web site hosted on the system. Even a new user account gets chruby (with the auto feature) in its shell via global shell initialization scripts (with bash). It doesn’t suffice for the new user to just rip the chruby stuff out of the local .bashrc or .bash_profile, because that’s not where it is. It’s in /etc or somewhere like that.</rant>