I'll certainly admit that I don't know the gems packaging system as well as I know dpkg and aptitude, but I think that that criticism misses the larger issue.
You're certainly right that the gems system could be made to do everything that the Debian/Ubuntu system does, particularly if given time to mature. But as I pointed out in my post, this wouldn't fix the problem.
Apache, for example, has hundreds of modules, each of which have complex dependencies.. They're released on their own schedule, and they're released across lots of platforms. Firefox has it's own set of extensions, and updates- You see the same thing with CPAN, and Python modules.
But the more disparate systems you add, the more sets of configurations you need, the more repositories you need, and the more ways to update everything you need.
So for our servers, I could set up a Gems repo, an Apache repo, a System Software Repo, a Cpan repo. I could have separate upgrade commands for every software package that comes along.
But the complexity is increased with each addition to this system-
* If I want to get a list of everything that's installed under this system, I need to run X commands.
* During installations, I can't chain everything together, I need to run X set of separate installations.
* I need to review X different release chains, to see if there are packages I need to test before deploying to multiple machine
* And yes, I need to learn X different systems for installing software, rather than one system for installing system wide.
There are a lot of good reasons to have the gems system, and I think it's a great tool for individual systems, but for anything that's going farm-wide, It's substantially easier to have everything go through one tool.