A very important, but missing point is that the CMS should not only be a web CMS, but a general-purpose one (ECMS, or enterprise content management system) - in which I have the ability to define my own content types and their relationships.
In my opinion, multiple database engine support is not relevant, as long as it supports a well-known and maintained database engine that makes sense for the technology stack.
For me, the following are very important:
- High performance - not only the performance, but a well-documented way to benchmark the product against other CMSes is very important.
- REST API - nowadays you can't afford to build a system without the capability to interact with external components in some way, and a REST API is a very elegant way to solve this problem. It is also useful because you can call it from client-side scripts in the browser.
- Customizable UI framework (or, in other words, completely replacible) - Developers using the CMS should be able to completely replace the default UI and roll their own, or maybe even combine their own with the built-in options.
- Well-defined extensibility points - Every layer of the software should be customizable with well-documented ways to extend the default functionality.
- Decoupled design - The lower layer of the CMS (usually called a Content Repository) should be a usable product on its own, meaning that it should work with other applications and custom user interfaces.
Here is a good article about decoupling content management and why the approach is important: http://bergie.iki.fi/blog/decoupling_content_management/
For further reading I would also recommend the book called Content Management Bible by Bob Boiko.