I think generally the problem is twofold. First, as the GP pointed out, design decisions (both technical and aesthetic) are made by people who aren't programmers or end users. These people care more about documentation and 'The Plan' than solving the problem elegantly.
The second problem is that most 'technical' people doing in-house enterprise apps aren't that great. I know this sounds callous of me, and there are definitely still great people here and there, but the average ability level is pretty low. My 'enterprise architect' has never even used Java 5 (her excuse: she hasn't had any training for it yet). People like this aren't going to be confident enough to suggest (or even aware of) alternative implementations to those given them by the 'design committee'.
I just started a job doing 'Enterprise Java' (gotta pay the bills until grad school this fall) and they have me working on this project for the next 6-7 months. Once I finally parsed all the buzzword bingo documentation, I realized that what I'm implementing is basically a read-only ORM.
The design as I'm given requires 15+ lines of Java to get a single object back (you know, Post.find(:title => 'foo')) and requires the end user to know which table goes with which DAO goes with which business object, among other things. I'm slowly but surely getting changes approved by my 'architect', and hopefully will, in the end, have something a little more sane.
The fact that they are paying both me and her for six months worth of work to do something that really could be handled by an existing ORM definitely doesn't point to in-house 'Enterprise software' being the cheapest solution. Throw in some of the ridiculous design decisions and 'requirements of our company's standard architecture', and it's not really the fastest either.
As for the Enterprise software from vendors, I'd argue that the problem is that it's solving the problems of these in-house developers and managers, who only have the problems due to over-complexifying (not a word I know) what they do.