There are lots of other criticisms, but it's a fine data store, if you're dealing with data that fits it well. The best way to think of it is as a hash store - you can store N-deep hashes in it, index pieces of those hashes so you can find whole records ("documents") quickly, and that sort of thing. You can't perform table joins (or don't have to, depending on who you're talking to), but you mitigate that by designing your data such that you get what you need for a given resource in a single query.
Personally, I'm all on board with it for web apps. I think it fits your typical web app's data requirements far more closely than a traditional RDBMS does, and I'm using it very successfully in multiple production systems.
The biggest remaining fault, in the context of web apps (IMO) is the lack of transactions - if you have an application that requires transactions to ensure proper operation, don't use Mongo. Do recognize, though, that many transactional use cases are replaced with Mongo's atomic operation set.
While not ACID, "tension" documents are a good way to add a level of transactional support.
For example, if you want to update multiple documents, instead of modifying the original documents directly, you create a new document with instructions on how to update the original documents. Then, you roll through the tension documents and apply their changes. Any failures can be dealt with on subsequent passes, only removing the document from the scan once it has been successfully applied.
It is an eventually consistent pattern, but that is a tradeoff you have already accepted by choosing MongoDB in the first place, so it ends up working well for a lot of transaction use cases.
For example, in the canonical transaction example of Alice giving Bob $5 you could insert a document in the transactions collection that says Alice gave Bob $5. When you go to fetch Alice's pending balance you fetch her current document, then you fetch all pending transactions than she is involved in. Same for Bob and all other users. Then each night, you pull that days transactions and apply them to each user and update an "as of" field to make sure no transaction can ever be applied twice.
Now you could argue that this isn't fully consistent because it is possible for Alice to simultaneously give $5 to both Bob and Charlie even if she only has $7 in her account. However she will then have a pending balance of $-3 so it immediately reflects her current situation. This is similar to the real world example of overdrawing you checking account. If you wanted to, you could void one or both of those transactions if you never want to allow a user to go negative.
You could use optimistic concurrency control to ensure that only one tension document is written at a time while ensuring that your constraints are respected:
current_id = atomic increment global state_id
create tension document (but with active bit set to false)
check constraints
atomic:
if global state_id = current_id
set active bit to true
if active bit is false:
delete tension document and report error
The atomic operation in RDBMS is usually implemented in one very simple and fast SQL UPDATE query. I believe mongo must provide something similar too.
Although my bank would allow me to overdraw from my checking account, I have a higher margin/tolerance than my brother, so they must perform some constraints check ;-)
That flexibility comes back to haunt it in larger projects. A typo in a query can trigger a reindex of a huge collection, make moot GBs of index data, or invalidate other queries that work on the same collection. It also demands that the devs do lots of documentation on the data structures as you can't ask mongo to tell you it's schema, it's just a collection of documents.
And if you work with a loosely typed language, be sure to type your inserts as mongo is not a loosely typed datastore (coughPHPcough).
But for internal tools, and smaller projects, the speed of development is great.
Gotta sacrifice some flexibility for a bit of safety.