Having spent the last 7 years working on enterprise systems for insurance companies (at a vendor, not internal IT), I can point out a few less sinister reasons. Sure, design by committee never helps anything, but there are just some fundamental difficulties around enterprise software.

* The developers don't understand the software they're using. Everyone uses e-mail, so it's pretty easy to know if you're making a crappy e-mail client. I'm not a claims adjuster, so it's much harder for me to understand if I'm building a claims system that makes the most common operations too difficult, or presents the data in a way that doesn't put the most useful information together. Sure, we've got product managers whose job is to figure that out, but they're not really users either, so there's always something lost in translation. Building software that performs a function you yourself perform is just way, way easier to "get right" than building software for a function you yourself don't understand.

* As is pointed out elsewhere, for internal development projects (which a lot of enterprise software is), the economies of scale work against you. It's difficult to build anything robust and functional for under a few million dollars, so most likely you'll end up with something not-so-robust and not-so-functional instead.

* On the flip side, companies make themselves very, very difficult to sell to, which provides a very high barrier to entry for vendors. Part of that is historical: they've been lied to so many times over the years that I can't really blame them. Most of them have a long history of failed implementations and IT projects, and they're naturally risk averse. On top of that, they have all the usual corporate red tape that commons with massive purchases, and since the market for most of that sort of software is often relatively small (compared to consumer markets, at least, or to more general-purpose tools), vendors have to charge a lot for their software if they want to stay in business. Unfortunately for their customers, that means that it's difficult to sell to them, which lowers the number of entrants in the market, which reduces competition on the vendor side, which leads to poorer quality software.

* Enterprise software is often boring to develop, you don't understand the use case, you can't show it to your friends or family or anyone else that will care, the deployment model often sucks, if you're a vendor you have to make things configurable (which makes it 10x as hard to develop, reason about test, etc.), and the companies you're selling to make the sales process incredibly difficult. And that's just working at a software company; obviously corporate IT in-house work is even less appealing. Understandably, the most talented developers often choose to work elsewhere. My impression these days is that the "you can't show it to anyone" bit is the most important for people; if you work for a company people have heard of or on a product people have heard of, you can take pride in showing that off, and not having that ability to show someone the cool stuff you're doing takes away a lot of the fun of software development.

* The small market and difficulty of deployment generally means that real user testing is difficult and costly, so people just don't do it. As a vendor, there's not much we can do (we can and do go watch people using the software, but there's not much we can do before we ship a version), and that's not a core area of expertise for the IT departments that are installing the system (or building one themselves). We can't just throw something out over the web and do A/B testing, or push a new version and roll it back if people report too many bugs.

* The market isn't yet there for hosted enterprise apps, so you're stuck with in-house deployments for now. I've commented on why that is earlier, but it comes down to both pricing, customization requirements on the customer side, integration requirements, and market valuations. It might work for certain types of enterprise applications that have large enough markets to make it scale, but for industry-specific systems where the target market is in the 1000's of companies, the math doesn't really add up.

There's definitely an opportunity there for a company of talented engineers to disrupt some portion of that market (which is what I like to think Guidewire, my employer, has done). But it's not as easy as just building a web app, attracting users, and slowly growing it: the domain-specific knowledge required is off the charts, and the barriers to entry are incredibly high.