I wondered about this myself as I wrote, but I wasn't 100% sure that CPAN could self-update. I don't honestly know why they're treated differently. (I also wonder about cabal and pip and luarocks, etc. I just don't know.)
Corrado mentions here that he would like to see Ruby/gems handled more like Perl/CPAN in Debian, but I'm not sure exactly what that means or what it would look like.
I read through all the comments to make sure no one else has responded. I'm more of a Perl developer then a Ruby developer, but these are my observations of the differences between the two.
1. Perl Versioning is more thought out. It tends to have more consistent versioning semantics. Experimental branches are done in odd minor versions. e.g. 5.11.x was the development version; where 5.12.x is the stable release. All further development occurs on 5.13.x, etc. Patch level changes on the stable version are for minor updates (that don't break compatibility) or security fixes. Major changes to the language that break things are enabled by explicate pragams. E.G. use 5.10; Major version numbers represent core changes to the language, and really represent a new language, that may or may not be compatible with the previous language. E.G. Perl 5.X.x V.S. Perl 6.X.x. This adherence to the value of having development and release versions trickles down to the modules themselves.
2. CPAN is both a tool and the Archive.
a. As a tool it is great for both developers and package maintainers.
i. For developers:
* it allow them to install bleeding edge modules.
* easily upgrade those modules
ii. For maintainers it allows them to:
* query the Archive for various meta information (dependences {build, release}, author, license, etc)
* download the modules and extract them
* allow the creation of build tools (e.g. dh-make-perl,pbuilder) that automate the packaging of the module
b. As an Archive, it provides a common place with an agreed upon standard.
i. Modules on CPAN can be marked as a Developer release.
ii. Modules on CPAN can also be marked as released version.
iii. All information in the Archive can be Queried by the CPAN module, that is part of Perl CORE
iv. Perl Core, the interpreter and build tools are well defined.
v. Core modules are also well defined, and do not change at patch levels.
So, package maintainers can easily package perl modules into their os specific packaging system.
To make a Debian package on Lenny from CPAN it's as simple as: dh-make-perl --requiredeps --cpan Module::In::CPAN --build
If all your dependences are already in the system this will generate a deb for you, if not it will tell you the modules it could not find; so you can build them.
Perl modules allow you change where things are installed by respecting the various PREFIX config options. From what I have read here, it seems this is not true of RubyGems.
I don't know enough about RubyGems to know if it does the additional things the CPAN tools does. But the main thing is Perl/CPAN works with Debian by following their rules, and making it easy for them to build deb packages.
I believe their reasoning is that they don't want a package installed and tracked via APT to be updateable outside of APT control and tracking.