I'm in Barcelona, where I presented this morning a wiki I'm doing for a client. A couple days ago, two of the contributors were arguing about the look & feel, one wanting to make things prettier, the other saying that it doesn't matter as a wiki is all about content. “It's ugly!” says one, “It's not, it's useful content!” responds the other. I was sure that this kind of conversation would arise sooner or later (actually sooner and on an ongoing basis). I did warn them upfront that this wasn't the kind of web site they're used to, putting the emphasis on both the content and the application sides that characterizes their wiki.
Of course, saying that websites are mostly good-looking empty shells while wikis are ugly piles of dry content is a bit extreme, but I'm sure you know the feeling. I came out yesterday with a metaphor to compare those. Traditional web sites are like whole milk, they taste great but can be fatty. Wikis are like skimmed milk, they taste like water but contain all the nutriments without the fat. One could arguably say that skimmed milk is healthier than whole milk, I personally settled on the half one although I love whole milk ;-).
More seriously, it's a fact that an empty wiki rarely looks good out of the box, and that may be discouraging or repelling for a lot of people. At the same time, it's also easy to fall into the classical trap of focusing primarily on the look, because it's easier (on the surface only) and funnier than producing and organizing content. Wikis are, in essence, web sites, so they don't escape the same design principles about usability, navigability, information architecture, etc. Another key difference here is that, with a wiki, everyone becomes an editor, and has a wide play-field that goes beyond simple content (just think about the importance of good hyperlinking for example). So the trick, for designers, is to find the right balance between making things look good while keeping the ease of use for both those who contribute and those who consume the content. Since not everybody is born a web designer, this explains why wikis are introducing a whole bunch of new roles, like gardners who will let people plant freely and later shape things up to help grow the wiki properly.
I would love to hear your experience about wiki design, and how that question impacts your choice of software.
 For the curious, it's based on Confluence from Atlassian, and does a little bit more than just a bare wiki. I hope I'll be able to tell more about the client and its project, as it could make a pretty interesting case study (insert climax with web 2.0, folksonomies, RSS and a David against Goliath fight between the small grassroots wiki vs. the big top-down IT-baked one-size-fits-all portal. Who will win? May be soon on a blog near you ;-).
 I'd argue that most open-source wikis really suck in terms of design. You know who to blame: software developers aren't exactly the best web designers, and web designers rarely contribute to free software. In my initial evaluation, the cost of design and custom code developments to move MediaWiki up to par with Confluence for the needs of this particular project would significantly offset the cost of the license. Wikis, unlike blogs, offer a good market for software vendors and a few are really striving.