The case for McMansion architects (part 1)

So I'm reading an interesting piece decrying "McMansion" software architecture and totally nodding my head. Raganwald's a better writer and smarter than I am (PLEASE DON'T HATE ME MR. WALD) and given that a recurring theme in his posts is casting "best practices" aside and being brutally intellectually honest about what you're doing and how it's failing and can be ameliorated, he's right. But as the devil's advocate with a massive failure of vision, here I go sticking my foot in my mouth.
It's an interesting article to be sure, but at the end of the day, it feels like it's restating Brooks' thesis on essential and accidental difficulties in software development (yes I just reread The Mythical Man-Month, what of it?).
There's a part of me that's totally nodding in agreement at being saddled with cookie-cutter
concepts and then there's another part of me that's scratching my head about what exactly is wrong with using databases and XML and all the other unsexy (proven) technologies that the anonymous architect has proposed to bring the app from a "telephone book sized specification" of requirements to an implemented product. There's a part of me that's giving an e-high five for sticking it to consultants who are paid too much to use a metric ton of buzzwords to not quite tell you what you already know and a part of me that's wondering what exactly is wrong with using COTS products and technologies since I'm not a world-class developer and don't work with world-class hackers and maybe I won't see as many exciting things on the road more travelled, but I won't fall off a cliff either.
I honestly feel bad for the architect. Think about it for a second - a specification that probably runs upwards of a hundred pages. I haven't seen the spec or the proposal, but I feel safe in asking the question - who could possibly put together a proposal that would sanely satisfy something like that? If I'm Raganwald, I'm probably going to outwardly scoff to anyone unfortunate enough to listen to me because I'm an asshole like that, but at the same time I've got to be happy that there's progress that's been made. OK, the initial draft sucks and the architect looks like a chump and here's a dozen reasons why, but at least we're moving from something proposed by a group of people (I doubt it was one person who was put together that specification; I'm assuming that it was spec'd by a committee and written by a couple of people) into a proposal that I can digest and critique and iteratively improve upon to a point where we have a good enough idea of what we're all talking about that we can actually make something.
The initial architecture proposal sucks? I'd be astonished if it didn't. Using XML is the wrong decision? Thank god we're far enough along that I can definitively say that. That's better than we were a telephone book ago.
Above and beyond the obvious problem (a mammoth spec), in handing it to an outside entity, you're dealing with some unspoken problems. That specification is ostensibly the crystallized desires of a group of people, but hiding deep beneath and in-between the lines are the unspoken desires of people that never made it in there. How much of what ended up on the cutting floor could be picked up and stitched together into a fabric that details the essence of what they're after? Was the spec handed off to a single person to trim the fat off of everything? Did they have the courage to ask the terrifying question that nobody wants to ask - do we really need to develop this and the added fortitude and singular vision to come to that conclusion on their own?
Maybe I'm just missing the bigger point because at the end of the day, I doubt I'll ever be the Le Corbusier of software development and I'm just totally projecting here.
I believe that it is possible to overcome the fantasy/reality impedance, but nobody's going to be happy when you do.