Also, Debian takes a lot of efforts to make different major versions run in parallel, like Ruby 1.8 and 1.9, Tcl 8.4 and 8.5 and so on.
Also, large packages like Ruby often have a boat-load of customizations and patches applied to them that may not apply cleanly to subsequent releases of that software. Modifying a debian package to build a new version is significantly more nightmarish than the RVM install process.
rvm is easier than creating your own deb or rpm
rvm is easier than doing your own packages, certainly, but imagine if you had to use an 'easy', but different tool for everything on your systems.
Also, 'easy' it may be, but I'm not convinced of how things will work out in terms of security, whereas I have a lot of trust in Debian and Ubuntu's security teams. Time will tell, I suppose.
For example, if I'm a ruby developer that ends up using different platforms often (osx, debian, centos) then it's justifiable that I want to use a packaging abstraction that's platform agnostic but ruby specific.
If I'm a primarily a debian user that happens to program in ruby and a dozen other languages then I would prefer a packaging abstraction that's tool agnostic but debian specific.
Or, at work it's basically the same thing but with java and maven to manage java stuff. Java's had a similar history of butting heads with package management systems.