I'd say it's partly because WCM is what is referred to in user experience design as an "implementation model". It's a category defined by technical considerations (library services, workflow, templating, etc), rather than by a user's idea of what they want to achieve. That kind of mismatch is a recipe for unsatisfactory software.

It's also a broad problem domain, with ill-defined boundaries. Nobody's quite sure which features are core and which are not. If the user model is "I want some software to update and manage my website", then the exact functionality that boils down to will vary wildly from website to website. What about analytics? Analytics certainly fit into the user model, even if it's not usually considered core to WCM.

So WCM solutions tend to end up with rather large codebases, as they grapple to deal with all contingencies. To make things worse, the web keeps evolving. RSS, UGC, Ajax, widgets, the web as a platform... Websites are much more complex than they used to be, and need a lot more managing. More significantly, successful websites are no longer islands; bits of them are embedded in or aggregated by other websites.

WCM vendors have struggled to match this pace of change. The larger vendors mostly attempt feature completeness through aquisition, building up huge suites of applications that are not necessarily very well integrated.

I think WCM has got to stop trying to be all things to all websites. Future WCMs will be a set of mashable services based around widgets and APIs that can be integrated into any number of different web frameworks, or even just social networks. Plus they will build mashable websites, delivering components to new, widgety channels.

Before you say, "but wait, your own PostCMS app doesn't do that!" - yes, I know. Not yet. But that's what we're working towards.