I really got a kick out of reading the Project Aardvark spec. Like Joel, I think a big design up front, is a superior way to get a project completed. While I like lots of the extreme programming dogma, the concept of getting the whollistic design down pat before you start to write any code is a great way to clear out a whole bunch of distractions, that can prove really expensive when you do them on the fly (in code).
I think that it's mainly about being responsible. When you're managing a development project, you have three things you have to concern yourself with: Schedule, Features and Resources. That's all there is to manage. Investing your precious resources on actually building features that might not make the product, when you could spend a week planning to avoid it seems irresponsible to me. And the other thing is that once you have an actual, code complete feature, it's heart-breaking to cut it. Deleting a paragraph from a document isn't the kind of thing you come home about and cry into your beer over.
Of course, you can't get everything right first up - there are always bits you have to add as you go. With Context ICE, (my current project - coming soon!) we left out a bit of functionality from our design (template generation) which has ended up costing us weeks out of the plan. The team still has to be able to adapt and change in order to get things done on time - the BDUF doesn't solve all your problems.
But it does make for less surprises, which means planning is easier to get right.