Good points, Dan. Some of the difference in perspective is between application data modeling compared to storage engine design. I'm not diving down the the implementation of the DBMS, so I'm sure I'm missing that angle.
One notable difference between MV and MongoDB is the levels of nesting, as you mentioned. I would contend that it is rarely a good logical data model for line-of-business software to nest deeper than sub-values. With the MV application I have worked with the most, sub-values were even forbidden in the development standards. This did not hamper the design or implementation. This make sense because MV aligns with language. Sentences that nest beyond nesting a list or association are typically too complex.
On the other hand, the ability to be able to implement an arbitrary JSON document (or XML) within the database structure (rather than simply as a text document that is then parsed) is a nice feature of MongoDB and other databases, such as Cache' globals.
So, yes, I'll grant that one.
The tight coupling of metadata and data is less clear to me, but I give the nod to MV from my perspective. I don't know how Mongo stores the data and metadata, but having descriptive rather than prescriptive metadata is a plus in MV. It allows the user vocabulary to be extensible (with synonyms and user-defined functions, for example), setting up for more natural queries. It is also very easy to refactor the data and metadata. On balances, it has a significant downside that there are not as many types of constraints within the DBMS, however. You get more rope to hang yourself with MV than with MongoDB.
When it comes to the distributed nature of MongoDB, it sounds like sharding is beyond painful, but yes, it ought to be more scalable as advertised.
BTW, I have talked with the MongoDB sales folks, and they would not really claim that a site can successfully deploy a production application with their open source DBMS. Some of the backup utilities are not included in the open source version, for example.
--dawn