First of all: does it give me a/the solution to the problem I have.

• It has a recent release
  Depends on the reason. A proven well-behaving module might not need a regular release.
  Way more important is a good ChangeLog with the release.
• The newest release passes all its tests
  Depends on the coverage (sorry BrowserUK, this *does* matter). It is easy to make a module to pass all tests if there is only one test that tests nothing: ok (1, "Make it PASS!"); is a legal but useless test
  I certainly prefer the release to pass all tests, but if the only FAIL'ing test is an ill-written test that depends on floating points being rounded to 12 digits instead of 32 on a system with long long long doubles, I do not really care. Likewise fir 1 nanosecond differences in speedtests.
• Its tests have good coverage
  Yes, but with well-defined tests. It is not hard to write a test suite that covers all of the code, without testing its functionality.
• It is of high kwalitee
  Prefered, as that shows that the author is aware of possible issues, but in the end it doesn't say a thing about the functionality, the usability or the correctness of the code.
• It has many MetaCPAN ++s
  Depends if the ++'s are recent. ++'s on version 0.12 from 2001 are not useful at all if the current version is 2.34 from 2019.
  And ++'s do not have to be for the part of the code I am interested in.
• There are no long-standing open bugs
  Depends. If I am working on Linux and the open bugs only affect Windows or vice-versa, I do not care at all.
• It is pure perl (ie. no XS)
  Preferably the other way around :) Most XS modules are way faster than the PP counterparts.
• It has no/few non-core dependencies
  CORE deps are fine: they will be there. Period.
  Non-core deps depend. There is no use in writing a DBD module without using DBI.
  I *hate* authors depending on useless non-core modules (however useful for them) like Modern::Perl, sanity, and common::sense. Depending on those are a red flag to me.
• Many other modules use it
  I agree here with BrowserUK: a useless metric if all those are from the same author. That would be an indication of reinventing a wheel.
  
• The author is prolific
  That is a void option. Way more important is if the author is responsible and acts/reacts in a mannered way to bug reports and/or questions. Check (recent) issues and tickets for questions and answers to see if the level of support is meeting your needs.
• It is as generic as possible
  Non-issue. Why would this be a reason to use/reject a module?
• The licence is acceptable (Artistic/GPL/BSD - delete as appropriate)
  *I* don't care, as long as I am licensed top use it for free.
• It has good reviews*
  Where? By whom? Do the reviews talk about the functionality I want to use or just about how well the GUI looks that I do not plan to use?
• It has extensive and clear documentation
  Very important. It must be up-to-date, complete and easy to read (not full of typos or words that only someone with a native tongue will recognize).
• It is recommended by a Monk
  That might help, though it of course depends on how well I trust that monk (agreeing with BrowserUK again).

And additionally

• A well defined minimum version of perl (with a reason)
• A complete META file
• A location for tickets (RT/GitHub)
• A location for help (IRC/MailingList/GitHub)
• An examples section in the docs or an examples folder in the dist with easy to understand code chunks
• Consistent code style. At least in the documentation
• A README and/or INSTALL doc if make install is not enough
• Conforms to standards (when applicable)