Curation creates bottlenecks, single points of failure and is very subjective.
The fact that members of the community are thinking about objective ways to measure modules is better for the community long-term. Quality of the code in packages is important because it suggests that the module will be more maintainable and extensible long-term. But that is just one factor.
I hope the community leverages weighted social proof as a way to suggest which modules are fittest and should survive and prosper. Those developers who are most active in the community and contribute the most are also people that ship code and rely on the code of others in the community. One of the best way to determine which modules to use would be by weighted popularity where the usage of a module by someone of importance in the community carries more weight than usage by a non-contributer.
Basically, the idea of number of "watches" and "forks" in github needs to be taken to its logical conclusion because not all watches and forks are created equal.
I would imagine that these are the kinds of issues the node community is considering as they try to come up with a scalable, objective way to manage what succeeds.
Personally I think this is a much better solution than the approach in other communities where certain library/technologies are foisted upon you under the auspices of convention over configuration. Some communities no longer just defining conventions that are widely adopted, but are picking winners and losers among newer technologies instead of allowing time for the community decide.
The community and open source projects around Node.js are growing too fast to subject it to curation and expect the truly great projects to emerge naturally.
As an endnote, the Drupal community and node.js community are fundamentally different in their approach. Drupal is an entire platform and framework, where many of the decisions of which module to use are make for you and you accept them or have to hack away to change that decision. This works in the Drupal community because by and large the problem space, content management, Drupal addresses is much smaller than that of Node.js, any problem that is better solution with asynchronous non-blocking I/O.