Counting mentions is okay, I guess, but there can be cases where something is just "famously bad", so that basing a decision on statistics alone would be unfortunate.

For the programmer facing the need to solve a problem, I don't think there's much we can expect in terms of avoiding an ad-hoc approach, but when it comes to breaking into a territory where numerous CPAN modules have already gone before, there is a progression of steps that should lead (more or less directly) to a good choice:

1. Compare documentation for readability: if a module's description of usage is hard to understand, you'll probably have trouble using it; if the explanations are clear and well organized with suitable attention to detail, there's a good chance the code was written the same way. **

2. Compare documentation for relevance to your task: among the modules whose descriptions you find readable, you'll see different ideas about how to approach the underlying problems, different ways of organizing resources, even different assumptions about the goals and constraints of the caller's application. Sometimes you'll pick a module because it fits well with what you're doing, and sometimes you'll rethink what you're doing to fit a module that looks good to you.

3. Compare documentation for ... (what can we call it?) "dedication" or "gravitas" or "grown-upness" or ... : check for things like depth of revision history, references to published standards or RFC's, and maybe just some subjective "gestalt" sense about whether the module author really "gets it".

4. Once you have a ranked list based on reading the docs, the next hurdle is ease of installation. Usually this isn't really a discriminator -- the majority of modules install easily -- but if your first choice turns out to depend on half a dozen other modules that you didn't think would be relevant (and that you haven't thought to review yet), and especially if one or more of those modules happen to fail "make test", you might consider moving on to the next candidate.

But let's face it -- a lot of us would just rather go to PerlMonks and post a SoPW node or mention a question in the CB, and there's nothing wrong with that, except maybe that we still end up (as often as not) with a lot of alternatives to choose from, and we're back to step 1.

** update: My apologies about that first point... it may have come across as being "Anglocentric" or prejudicial against excellent programmers who have better things to do than beat their heads against English grammar. I want to be clear that I'm talking about how specifications are outlined and how sample code is shown -- not about correct spelling, verb tenses, plurals or even sentence word order. If the docs are hard to follow because of limited English skills, it's worth looking at the code to see whether it's just a problem with English, and not a problem with logic.

For better or worse, Perl is a language dominated by English, but putting aside its function names and reserved words, its flexible syntax should seem fairly "familiar" to speakers of any human language, given an adequate amount of formal education.