Let me predicate this by pointing out that I manage a lot of Ruby projects (many are old) that require a wide variety of Ruby and gem versions. Obviously my solution isn't the best for everyone. Some developers will never have to worry about conflicting gem versions, because they work primarily on one project with one set of dependencies. The incremental value of the items I'm about to point out don't represent significant value to them. Enough with the disclaimers.
Bundler has the ability to alter your Ruby env variables so that you can easily install and execute gems from any location. This is the feature that allows you to use completely different gems across many projects without any conflicts. As the author suggests, you can pass a path at the time you invoke `bundle install` as a means to specify this location. This allows you to segregate gems to avoid conflicts. The author also points out that the trade-off is "one annoying side effect: any binaries that are installed (e.g. rspec, foreman, cap) are no longer available in your shell’s path". Bummer. I wonder if there's a way around that? Hey, we could manage our environment so that these items are in our path, but remain segregated. We could even write some tidy scripts that automate it for us. Enter RVM.
This is why I don't understand the drive to move to rbenv for developers who need these features. I use RVM and bundler all the time. RVM doesn't preclude the use of bundler, and bundler doesn't make RVM obsolete. When I establish an RVM gemset and .rvmrc, I've abstracted away all the '--path=./.somebundledir' and `bundle exec` nonsense. I only think about it once, then I'm free to use the tools without additional cruft. I'm probably happier than I should be that I can type `cap staging deploy:pending` instead of `bundle exec cap staging deploy:pending`.
If you don't need gemsets, or you're only managing a very small number of Ruby projects, I suppose I can understand wanting a simpler tool, but I don't find RVM terribly complex. A lot of people will say "choice is good", but principle applied without cause isn't good, it's just pedantic.
I don't want to get in to the rbenv vs RVM debate - they're both good tools and it's an issue that has been done to death. I linked to five articles in the post, and you can find many, many more with a simple Google. My personal motivation for switching was that bundler's overridden 'cd' function includes some commands that fail, which is fine under most circumstances but it breaks as soon as you use 'set -e' in bash. We spoke to the author and he said he said that RVM wouldn't be 'set -e' compatible in the foreseeable future.
My observation is that rbenv users often tack on additional ad hoc solutions to arrive at the same convenience provided by RVM. The primary objection I hear to RVM is the `cd` override, which is optional.