CPAN is great, but it suffers from Perl philosophy: "There's more than one way to do it" . Perl module authors not only re-invent the wheel: they argue stridently for the use of sleds, rollers, travois, octagonal wheels, and argue against development of roads, because roads aren't compatible with a travois, and "what about all those people who don't like wheels?"

CPAN is stuffed with great, good, bad, and terrible code all mixed up together; there's no consistent standards for versioning, there's no consistent standards for coding; like Perl, there's little, if any, consistent standards.

If you have to review all the code you're about to use manually just to know if it is robust enough to suit your purposes, you gain little, if any benefit, over simply writing the code yourself.

CPAN is stuffed with great, good, bad, and terrible code all mixed up together; there’s no consistent standards for versioning, there’s no consistent standards for coding; like Perl, there’s little, if any, consistent standards.

And that’s why it thrives. If it tried to enforce any of these to any extent, it would wither, like the repositories of other languages have.

PEAR, at the very least, is a wasteland. Ruby’s Gems thingie is doing better… but is orders of magnitude smaller than the CPAN. I don’t think Python has anything resembling any of these. Java’s central repository is called “Google” and the quality of stuff is all over the place – certainly less consistent than CPAN with its lack of standards… although the high-quality Java libs are consistenly good and well documented (though that barely makes the language any less unfun…). We’ll see where the JSAN goes – being a bit of an outlier in this set as it is.

This is why a Linux distribution will include Perl modules for your use. If you can't trust them then how can you trust your distribution.
Is a code review slower than writing your own? That's not a simple question.