I'm very skeptical about this sort of advice, especially when it is motivated by We do Ruby, we know what’s best. Trust us.
Ruby is a language that moves very, very quickly. On "cutting-edge" distros like Fedora and Arch it's not nearly as much of an issue, but not having to wait to get new language versions is very convenient.
More importantly, though, is that the version of RubyGems distributed through Debian's (and Debian descendents like Ubuntu's) package repositories is crippled. Gem normally includes a very important command called 'gem update --system' that lets you upgrade gem itself. The opinion of the Debian package maintainers is that all upgrades should be handled through the package manager. This makes sense from a system administration perspective, but it's a huge pain when you're trying to do Ruby development, because important gems like Rails often require a fairly new version of RubyGems. (And Ruby libraries get updated much more frequently than the language itself.)
For the above reasons, doing Ruby stuff on Debian/Ubuntu without using RVM is a huge pain. Even if you manage to get everything working, an update to gem or something else may break it a week later.
While RVM isn't as essential on other distros (like Fedora, which I did Ruby dev on for a long time before learning about RVM), it's still massively convenient. You can ensure that you have a consistent development environment across computers and operating systems (which I find is especially useful when deploying to a server, since I use different Linux distros for everyday use than I do for hosting things), you can easily switch between Ruby versions (I have one project still on 1.8.7, and I do the rest of my stuff on 1.9.x--switching between them is as simple as typing rvm $VERSION), and it deals with all of the icky bits of managing multiple versions of gems (to go with your multiple versions of Ruby) for you.
RVM is awesome, and makes lots of the headaches that surround Ruby development go away. Use it.
and later
> "This makes sense from a system administration perspective, but it's a huge pain when you're trying to do Ruby development"
It's a developer's world.
Having been a Rails programmer working on some internals projects in the company that I used to work, I like both Ruby and Rails.
But now I'm' working as an operations guy (ie, a sysadmin) in a new company, we came short of adopting redmine and maybe opening the road for more ruby and rails software to be used, we already use puppet and so every sysadmin now knows ruby, so it would be good to include some more ruby to internal use, but it was just a pain in the ass to maintain the rails-based infrastructure, in both Debian and CentOS, the distributions that we use. Fedora and Arch is not used in the servers, so it cannot be used.
This is old, and just touches one aspect of the problems (shared hosting, which I do not deal with), but it does have some good rants, specially the point 2 of "How it could be better": http://blog.dreamhost.com/2008/01/07/how-ruby-on-rails-could...
I'll follow up after I'm done with Christmas celebrations, but to think that a random hodgepodge of flavor-of-the-week deploy scripts slapped together by a webdev and scraped from github are somehow better or more maintainable than the collaborative output of some of the world's smartest and most committed developers is flatly-ridiculous.
Follow http://planet.debian.org for a week and tell me these people don't know what they're doing.
I'm really not interested in getting into some back-and-forth flamewar about this. (There's been plenty enough of that on the Debian mailing lists and elsewhere already.) I trust that the people maintaining Debian are very smart and do, in general, know what they're doing. But I don't trust that the people maintaining Debian know how to deploy Ruby/Rails better than the people in the Ruby/Rails community.
EDIT: Well, since you cannot answer in this thread feel free to answer in my first comment in this thread above if you wish.
EDIT2: I found this article about the matter, I found it to be good, I agree with him in the large picture: http://rcrowley.org/articles/dependencies.html
RVM automates the compilation step. I'm not sure why I'd want to do that by hand instead.
Gem installation is done on a per-app basis using bundler[0] or RVM's gemsets, so the gems for each application are kept separate anyway.
Running different applications on different versions of Ruby at once is also easy with project-level rvmrc files.
And if for whatever reason you want different RVM installs for different users that's easy too: RVM only installs for a single user by default.
Now, granted, I don't do anything like run a shared hosting service, and there may be cases where RVM lacks the flexibility to do what's required, but I've never run into them.
technomancy summed it up: "The rubygems devs have asked nicely to get Debian to fix these issues, and have been turned down flatly... Debian is the only distributor who breaks rubygems when packaging it."
Must we go through this whole debate again?
Fortunately RVM gives the best of all worlds: it's consistent between distros and operating systems (I develop on OS X and deploy onto Ubuntu and Cent OS--everything works the same in both places). Switching between ruby versions is as simple as `rvm 1.9.2`. You can easily specify a ruby version to use for different scripts, ensuring that whatever is best for a particular program can be used. And most importantly, it just works.
RVM is in my mind the biggest improvement to ruby development in the last couple of years. I'm sorry if the Debian packagers feel its encroaching on their territory, but it serves our needs as they do not.