Many of those reasons for; I consider to be reasons against:

• It has a recent release

  Under active maintenance could be a plus; but it also means it needed maintenance.

  In other words, it completely depends on why a new release was required.

  If the release fixes a reported bug, that's good; but if it adds (unrequested and/or unnecessary) new functionality to an existing, working module with no reported bugs -- eg. non-Q functionality added to the Thread:Queue module by the new owner -- it's bad!

• The newest release passes all its tests

  As stated, this is neither good nor bad.

  Did the last version also pass all tests? Were the changes required? Were new tests added to cover the changes?

  Basically, a nonsense criteria.

• Its tests have good coverage

  A definite negative.

  Any author that has bought in to the fiction that automated coverage tools serve any useful purpose is suffering from cool-aid intoxication and thus delusional.

  The idea that adding tests to test stuff that doesn't warrant testing, simply to satisfy a dumb automated coverage tool that has simply no knowledge of what needs to be tested, is the very height of TDD arrogance.

• It is of high kwalitee

  Definitely negative.

  If they can't even spell the word correctly, what chance that anything else they do is useful!

• It has many MetaCPAN ++s

  "7 out of 10 cat owners said their cat's preferred it."

  Which 10 owners? (The ones who accepted your offer of a lifetime's free supply if they signed off on you quoting them?) And do they all have talking cat's that could inform them of their preferences?

• There are no long-standing open bugs

  Depends if the long standing open bug affects my use of the module.

• It is pure perl (ie. no XS)

  Non-issue.

• It has no/few non-core dependencies

  Can be a recommendation; but the opposite (has many) is a much stronger negative for me. eg. Moose which seems to try to use every module on cpan even if it only requires a single 1-line function from it.

• Many other modules use it

  Can be a recommendation; but only if all (or most) of those other modules are not by the same author.

  eg. less is (or was) included in dozens of modules despite that it does nothing and never will.

• The author is prolific

  Usually a negative unless proven otherwise.

  Prolific module writer's often write modules purely for the sake of being prolific! They write modules in absence of having a real-world use; thus they do little real-world research or testing and define interfaces in terms of what is convenient to the internals of the module; not the convenience of real-world calling code. They also tend to fire-and-forget; write, passs the tests they thought of and upload; and never again maintain.

  There are exceptions. There are some prolific authors who produce exceptional modules; and provide exceptional support to them all.

• It is as generic as possible

  Generality in a module is (nearly) always a bad thing.

  Jack of all trades, master of none; lowest common denominator; bloated and overcomplicated, slow and clumsy. the very antithesis of the Unix philosophy:"do one thing and do it well".

• The licence is acceptable (Artistic/GPL/BSD - delete as appropriate)

  Utterly irrelevant!

  Firstly, there are so many of these meaningless licenses; and no one -- not even the lawyers -- know if any of them would stand up in court. The best anyone can say is that if you come up against someone with enough money to flush and the arrogance to keep going, your gonna loose. eg. Oracle .v. Google

• It has good reviews

  Beware prolific review writers. Read all the reviews before taking the star rating at face value. Realise that there is no mechanism for indicating a negative review, so even a disastrous review (like: This module produces completely the wrong result.) can at worst give a 1-star rating. Add one review by someone who found it easy to use but hasn't realised it produces the wrong results with a 5-star rating and the module has a 3-star average!

• It has extensive and clear documentation

  Extensive is the antithesis of clear!

  If a module requires extensive documentation, it should probably be more than one module.

• It is recommended by a Monk

  Depends on the Monk.

  Sundial regularly recommended Parser::RecDescent, despite that it is bloody obvious he never used it.

My criteria: 1) Do I need it. 2) Does it work. 3) Does it work efficiently. 4) Does it only do what I need to and not a whole raft of other things that I do not need. 5) Does it have none, or only a few necessary dependencies.