When someone suggests an enterprise CMS, the usual best case outcome is to go back to the requirements analysis and remove enough requirements until an enterprise CMS is not required.

I've done my fair share of work on the things over the years and the outcome has never been the best one for the organisation.

Sitecore and Episerver are quite "popular" (probably not really the right word) in some circles.

People keep trying to make it so you can build complex sites and applications without coding, and in the end, what you end up with is far more complicated, fragile and inflexible than if you had just stuck with a normal development pipeline. Drupal's insistence on being both a product and a platform out of the box is what got them into this mess in the first place. They overestimated how much different use cases have in common, so they had to bolt on late-binding and lazy evaluation all the way up into the presentation layer.

I don't know if this is solvable. A CMS is complex enough that each of its functionalities deserves the care of good product and technical designers. These pieces ought to then be integrated into a cohesive whole, a la carte. For desktop software, we were able to pull this off pretty well, with 2000s OS X as the most cohesive, successful attempt, dictated by strong design guidelines and solid enough tech... And note that they invisibly transitioned CPU architecture along the way! But when online collaboration and multi device access became a requirement, everyone flailed and forgot the lessons of the past.

I don't think the current software market is capable of something like that. Almost everyone is trying to make captive SaaS where compatibility only exists on a service-to-service basis, in a subordinate manner. Branding is more important than cohesion, and flexibility and interoperability has taken a back seat to dumbing down.