A lot of CPAN's libs are likely cruft from the language being so old, the size of it says nothing. What's more interesting is how often libraries are updated with new code, and how often people use them.
Want to see how old code stacks up in testing? Let's pick a module and see all its dependencies and their test results. XML::Feed as a random example: http://deps.cpantesters.org/?module=XML%3A%3AFeed&perl=lates...
Hmm, says no results for some of them. Let's drill down and select HTTP::Negotiate to see its test results. http://www.cpantesters.org/distro/H/HTTP-Negotiate.html
Looks like the latest version has been tested on lots of platforms, and it's good! Let's pick a different piece of code, something older, say from 2005? https://metacpan.org/release/DOMIZIO/CGI-Builder-CgiAppAPI-1... http://www.cpantesters.org/distro/C/CGI-Builder-CgiAppAPI.ht...
Ah! So we see the last version it worked with and on which platforms, but on the latest perl it's failed its tests. We can drill down and see why the tests failed: http://www.cpantesters.org/cpan/report/c91a8b7c-4983-11e1-94...
Hmm, unprefixed autoloaded parameter. That's probably not too difficult to fix. I guess even though there's old crufty code that isn't always maintained across versions, we have pretty good visibility into when something failed, and with good tests we know why and how to fix it.
There's a lot more resources to take advantage of through CPAN, like bug trackers, review sites, development wikis, etc. http://en.wikipedia.org/wiki/CPAN
A bad sign. This is usually the result of a single test hanging indefinitely, leading to the necessity of killing the entire automated testing process. As a consequence the test results don't get sent to cpantesters.org, putting the onus on the user to file a bug report.
Yes you're right that CPAN has older stuff in it compared to say rubygems.org. It also has, as a gross generalization, older programmers with IMHO more mature and thorough approach to how they package reusable code. This is a language adopted first by graybeard Unix sysadmins in the late 80s and early 90s, then by the first generation of "CGI" web programmers, then by what we'd call today "web developers."
So the fact that CPAN contains old code has tons of upsides because the CULTURE of CPAN was set by more seasoned programmers. The documentation, for example, is of generally much higher quality than in Ruby gems, typically involving a nice Synopsis with lots of pertinent examples, documentation of methods/functions that thoroughly lists params and expected output (imagine that!), and that actually discusses edge cases from time to time. There are usually tests that actually run; by default a CPAN install runs a test suite which must pass before proceeding.
Rubygems are great but unlike CPAN which began as a manual system where adding a module involved dealing with judgmental humans it's all automated, making an account takes a few seconds and there are no real standards. The culture is just different. This has benefits, like lower barrier to entry, but downsides too. I am continually appalled at the level of documentation in common gems. I guess people expect you to just look at the code, as "view source" options abound in online docs, but then you end up chasing a code path through many methods and classes just to figure out the basics. And there are often real issues with the code, too; while Ruby has plenty of users, they are disproportionately Rails devs who stay in that little ecosystem, so a general purpose Ruby module tends to have fewer eyes on it. Don't get me wrong there is lots of high quality amazing stuff in Rubygems and I'm grateful for it, but you can't spend much time on Rubygems and NOT end up seeing a general difference in standards vs CPAN.
Anyway my point is older != cruft and older != bad. Older often means "used by many people for many years, with many bugs removed and many useful features added." Here's one small example. Let's say you want to pull a query param out of an HTTP request. You don't know in advance if it is a GET or POST. In Perl the (c 1994) CGI module solves this trivially without you having to drill down into how the requ was made. In ruby there is no method-neutral way to do this, you have to reinvent the wheel, inspecting the req, sniffing method, and (if you're using any of the code suggestions on Stackoverflow) MANUALLY splitting out the params by decoding the query string and splitting on ampersand. No one has solved this problem with a Ruby module (probably because if you're using Rails, as everyone is, there's a helper for this task).
People call Perl a "read only language" but CPAN's "old" culture makes code re-use more easy than even in a more elegant language like Ruby.
For a long time, it seemed like everyone was using his form mail and web forum scripts.
It cured me of any inclination I might have had to actually learn and use Perl.
I wish I could recommend perl - CPAN modules generally really are amazingly high quality. But the mental cost of the perl programming model: no named params! arrayref vs array vs list! Contextual::Return! blessing scalars into objects! - that cost is just so friggin high that I can't imagine asking anyone to follow me there anymore.
But you get named parameters (and type checking of them!) for functions/methods through CPAN. And lots of other language extensions.
High flexibility in programming languages -- Perl isn't close to e.g. Lisp macros -- do have costs, of course. You need to use automatic tools, code reviews and coding standards. But you should do that anyway.
I really doubt the extra time/cognitive costs make for a noticeable extra burden, considering that you'll have to learn lots and lots of other stuff anyway.