I chose Magnolia (www.magnolia.info) again for my third Content Management Solution. And, I still like it. Though Magnolia is capable of much more, following are the reasons I prefer it.
1. administrator managed public viewing site
Magnolia comes with role based security. It is extendable as its security is based on JAAS (Java Authentication and Authorization Service). Branches of the site can be secured based on role and roles can be configured with read/write access rightes. Roles and permissions can easily be managed and modified.
2. wsywyg editing
Magnolia adds its own javascript based controls for editing the pages. The controls apprear in edit mode and are hidden in preview mode. They do not exist in published pages. I would not call it 100% wsywyg editing, as Magnolia does not allow you 'inline' editing of the pages, but it allows you form based editing in popup forms. It still qualifies for wyswyg as the preview mode of the page is exactly how a published page would look like.
3. complete control over look & feel of the site
Since you as a developer create templates for the page layouts, and templates for the paragraphs, you have 100% control over how the site looks and behaves. I think this is the 'most' important asset of Magnolia. I've seen many other CMS solutions that allow you to create a page and paragraph layout with web based tools, but with any web based tool, there come certain limitations. With Magnolia, since a developer codes the templates, there is no such limitation. (Yes, the newer versions of Magnolia have some online template builder tool (Sitedesigner), but I have not used it, so I cannot comment on it. Also, it is part of 'enterprise' build)
4. database independent implementation
Magnolia stores its data using jackrabbit Content Repository. And, since you as a developer create dialogs (to capture data) and paragraphs (to display data) and you use magnolia's tag libraries to access data for publishing, there is not much jackrabbit know-how necessary to create a magnolia solution. But the fact that you do not have to configure a database as part of implementation is a plus. One less thing to worry about while deploying your magnolia solution.
5. a simple workflow, create - preview - publish
The workflow is simple. A content manager creates a page, previews it and if satisfied publishes the page. I think, for a vast majority of CMS solutions this simple workflow works and suffices. As a developer you can stack multiple installations of magnolia to create more elaborate workflows, like create - preview - review - confirm - publish, but I have not implemented such a system. I have read it is possible, but I'm not sure what baggage it comes with. I would still recommened a good understanding of Magnolia and its capabilities in expanding the workflow before you 'reject' it for any other tool, if a more complex workflow is required.
What else?
Now, is there something that I would like to see in Magnolia that it does not provide? Of course yes. No tool is perfect and no tool gives you 100% of what you want. The reason a tool is a 'good' tool depends on how easily it 'allows' you to reach your 100% beyond the 'X'% it gives you.
So, I would like that Magnolia provide a good 'eclipse' project, so that developing templates is much easier. (No, I'm not saying an 'eclipse' project to work on magnolia code itself.. I'm talking about an 'eclipse' project for creating and managing templates and other code artifacts (such as docroot artifacts))
I would also like that it is more seamless to adding custom code, like servlets and jsp's. Yes, it does allow, but it should be more seamless. And good integration of jsp's that read managed header/footer from magnolia templates.
I would also like more pre-built modules, like a blog or a message board. Though I'm not sure if that really adds value to Magnolia. But it sure will make it more competitive, as its competitors 'boast' of such 'out of box' features.
So, in short, Magnolia is a good tool to create highly customized and managed public domain websites.