1.) Ends with the same net result for the developer, and
2.) Adds a little bit of complexity on setup and rules around use, then
why switch? I'm perfectly willing to trade up my development tools, but I want a better net gain before I switch.
Perhaps that net gain will be to keep up with a growing number of devs who use it? We'll see.
Boy did you overreach on this one. What about rbenv constitutes the "proper way" versus a tool like RVM? If the argument is that RVM abstracts away too much of the underpinnings, then you've just a made a philosophical argument that is in conflict with much of the work that we do as developers.
RVM is simply an environment manager. One should always understand the environment that they're managing, but using tools to increase the efficiency of that management is not in violation of the "proper way". If abstraction of underlying complexity is bad, we shouldn't be using bundler, rbenv, or even init scripts and package managers. We should start all system processes with the direct invocation and build and install software by hand, lest we not learn the "proper way".
If we accept that abstraction is not necessarily a bad thing, then we can recognize that there's nothing about rbenv that is any more "proper" than RVM, and we can all use the tools we prefer.
I prefer not to have to append '--path=./somedir' every time I run `bundle install`.
I prefer not to have to prepend 'bundle exec' to every shell tool in my toolchain.
I prefer to have all my rubies and gemsets organized in a single location instead of spread out across my projects.
I understand that by using RVM a background process is altering my environment. I also know how to run `rvm info`, read the output, and understand the terms.
Those are my preferences. They're no more right (or wrong) than yours.