Says clemburg:

I thought that was the purpose of the "discuss your module before submitting it" part of the CPAN module procedure.

Perhaps it is. In that case, I submit that that part of the procedure is failing to serve its purpose, and we need to find a more effective solution.

And should CPAN shoulder the burden of organizing the whole process around it, and take the responsibility for (always possible) errors?

Here is one way it might work:

• There is a standard format for quality assessment reports.
• Individuals upload reports to their CPAN directories.
• The CPAN librarian compiles a nightly index of all the reports.
• CPAN.pm has a feature that will download, summarize, or display all the reports about a particular module.
• The person downloading the module gets to decide which reports to believe or to heed.

As the reporting system becomes more robust, other developments would be possible. For example, CPAN.pm might be configurable with a list of trusted people, and would display a warning before installing any module that wasn't recommended by a trusted person.

There are a lot of other ways that it could work; this is only one of many possibilities.

But where is the incentive for people to put their energy into code reviews, when the majority of the community does not value this service?

I think that if the issue were more visible, people would be more interested in addressing it. Once the review system was in place, it would snowball. People would start saying things like "I chose Text::Template because it had been reviewed and HTML::Template had not." Module authors would seek out reviewers and would start to exchange review services with one another.