Morbus Iff has a nice rant about the quality, or at least the style, of code in Drupal's contributed modules. And he's right - I was looking for a simple vote up/down module this week and ran for the hills after looking at the source code. Part of the problem isn't really a problem - it's debatable whether contributed, third-party modules should use Drupal's code conventions or whether it's up to the author to use whatever suits them best as long as it's consistent (I'm leaning towards the latter, as I prefer to use single-line conditional clauses, for example, and some of the 'gold standards' set by core modules aren't particularly optimal).
I think a big problem with the third-party modules - and the same is true for Wordpress and other open-source projects that anyone can write extensions for (which is a good thing) - is feature creep. A lot of the time it's easier to have a look at someone's gigantic existing module that does everything and then write your own version that does just the thing you want and does it well. Drupal.org's issue queues for each module are full of feature requests, and authors feel the pressure to dump these features into the main module when they might arguably be better off adding hooks and implementing those features separately, so that anyone can still get the original, single-purpose module without worrying about bugs, security holes and untidy code in the mass of extraneous features.
As Morbus suggests, separate module ratings for 'features' and 'code quality' could be useful. In fact, a lot of Drupal - including the IRC channels - could do with a separate focus on 'third-party developer'-specific documentation, support and features. At the moment that channel is mixed in with each of the 'core developers' and 'GUI users' stuff, which makes development more difficult that it need be. Drupal can be impenetrable to say the least, and not having a dedicated support channel can be frustrating.