Well-factored code is beautiful. When you sit down in front of someone else's program for the first time, and in short order you've not only found the piece of functionality you're interested in, you understand exactly how it works, that's the first, most difficult step on the road to making a fix, or contributing a feature already done for you.
Coding for clarity is important when you sit in a cubicle, because the guy down in the next office will have to maintain whatever you've just written, and any extra time he takes because of your ugly code costs your employer money. However, coding for clarity is even more important in an Open Source project, because the big advantage of Open Source is the number of eyeballs you are going to have looking at your code, and given the huge density of Open Source projects out there, if those eyeballs can't see what you're doing, then there's a good chance they'll not bother looking any more.
The more readable your code, the better chance that a complete stranger will mail you a patch, rather than a bug-report. The better designed your code, the more chance that a complete stranger will be willing to add a feature.
The problem with well-factored, well-designed code, is that to start with, it's less efficient. In the early stages of a project, you trade in the opportunity to use a faster, but more complicated algorithm, against the opportunity to use something that can be understood at a glance. You design encapsulated components, knowing that it would be faster in some cases to mix the code around and break encapsulation. Later in the development, of course, this turns around - once you have a fully functional system, well factored code is easier to profile accurately, it's easier to locate which optimizations will noticeably affect the speed or size of the overall program, and the code itself is more malleable, and thus easier to tighten in the right places. The problem is that software written using the Bazaar model doesn't have the luxury of hiding the program until it's ready.
There are several problems with releasing un-optimized code. Firstly, the majority of users of Open Source don't read the source. They either download binaries, or download the source and look at the options for
./configure. There's several million lines of available sourcecode making my Linux workstation run, and I don't have the time or inclination to look at most of it, even if it goes wrong. The practical upshot of this is that when something runs slowly, or uses up a lot of memory, or both, you uninstall it. You never see that the program is doing everything right, it's just not reached the stage of being tightened up.
As a culture, hackers tend to idolize great feats of efficiency. Mel the Real Programmer is our hero, never mind that (or more likely, because) the narrator in that story took two weeks just to figure out how Mel's optimization hack worked. There is nothing more evil to us than inefficient code, and "bloat" is almost the most unspeakable obscenity.
When a program is missing features, it's easy to explain to users that the feature will be included later. When a program is slow, or uses up lots of memory, people are much less likely to believe that this is something that will also be fixed in the course of development.
As a result, many projects are labeled "slow" and "bloated" before they've even reached the phase of heavy optimization, (three that spring to mind are early GNOME, Mozilla and Enlightenment), and even when they do speed up, they hang on to the damning labels for much longer than they deserve. Mozilla is still slow in a number of critical areas, but despite what Netscape might have us believe, it's still pre-release. Compared with the milestones of six months ago, it's flying, and the profiling and optimization work continues. Or in another example, Enlightenment reached the stage where the window manager had gone through a ground-up rewrite, but people still judged it on the performance of a very early development release, and wouldn't touch it with a bargepole.
So, the question is, do projects that release early and often open themselves up to unjustified labels, because they dared distribute unfinished work? How can Open Source projects protect themselves, without having to submit to the evils of premature optimization?