Well, as is often said, simple is not easy. :) There's a large effort by the CPAN testers community to run every module (and every new version of it) against a large array of hardware and operating systems[1], and provide automated reporting to the author of any problems.
This is possible because of (and incentivizes) the other great aspect of CPAN and the public modules which are on it, which is a strong culture of good test coverage of modules, and the CPAN clients running all tests and failing to install by default if any tests fail that weren't expected to. It's another wonderful feedback loop, and one not encouraged or discouraged by most languages specifically, so the fact that so many package managers for languages decided not to do so is unfortunate. When you don't start with that as an expectation, turning it on at a later date likely just results in a horrible user experience as a large number of module just fail to install (or at a minimum spew warnings which are confusing) because they are exposing what was previously something only the author saw most the time.
Not having good documentation means nobody knows how to use your module without a lot of work reading the code. So modules get documented or they get ignored. Thus, the modules on CPAN you know about and that are commonly used and relied on by other modules are the ones that have good documentation. It's self reinforcing. I imagine in a language that funnels use into a single or small set of idiomatic ways to accomplish most tasks, it might be easier to skimp on documentation and rely on people to fall back on the "obvious" way to things.