Note: I'm being brief, not trying to be snarky -- I'd love to hear what's behind your statements.
> - It does not scale.
What does this mean? I'm not saying you're wrong, but without some context, that doesn't say a whole lot.
I recall one big consulting company dropping Plone (and zodb) some five years ago because zodb/plone scaled to about 10.000 documents, and using a custom index solution based on lucene they managed to scale to around 100.000 documents for their cms -- but they ended up needing something else for "their biggest" clients. Can't find the link or remember the company now (I believe it was a German design shop). But it's the only story I've heard about zodb not scaling for it's typical use case?
> - Poor supprt for replication and sharding.
Are you aware that ZRS is now free and open source?
http://www.zope.com/products/x1752814276/Zope-Replication-Se...
> - It is slow. Really slow. Un-pickle every time you get something from cache.
You have to marshall structures that you load in a different way too -- is this really something specific to zodb? Are you saying unpickle is slower than other ways to marshall python objects?
> - It is error prone. Forget a commit or forget to handle conflict errors and you're in big trouble.
As opposed to not handling transaction errors with a postgres backend?
> - No interoperability. Want to write a service in C++ to access your db? You're out of luck.
>
Well, it's an object database. The only other I know of off the top of my head that I know people are actually using, is Gemstone. You could of course wrap zodb in a xml/json api -- but yes, I don't think interop with other languages is a good fit for zodb.
> - Some server side stuff needs to have your objects, e.g. if you want to do conflict resolution.
> - Migrations/change to schemas are painful, once you change your object you're no longer going to be able to de-serialize it.
This is a problem I'm constantly running into with Plone and a more or less well understood set of third party add-ons. I really think the smalltalk image approach is better (if you have the "data" you also have the "behaviour" -- with zodb you might have a serialization of a complex class, but not the ability to marshal it).