This is textbook projecting. The team deployed an immature database and tried to push its limits, and now they're saying: "it sucks!". Sure, a 2 year-old database is the problem, not your ability to make architectural decisions. Sounds like someone is looking for a scapegoat. They took a risk and failed and this is just a poor way of coping with it.
It's OK to publish your experiences on your blog (which they did a few days ago). It's NOT OK to go around the Internets publishing "anonymous" articles about how MongoDB sucked for you, as if no one will see what you did there. That's just defamation, folks.
On a side note, we also looked at MongoDB and, after running a few tests, we concluded that it is a glorified key-value pair storage. That said, we did use it in a few small-scale projects and it works great.
The bottom line: choose the right tool for the job and don't bitch about the tools when you fail.
I would say however that a significant subset of NoSQL deployments (perhaps even a large majority) are by definition lacking in sound architectural decisions. I'd argue the same goes for ORM-based database access too.....
The failure exists because many developers don't ask a few key questions up front:
1) What exactly can the database do for us?
2) Which of these do we need? For example, is the database going to be a point of integration?
3) What failsafe or security measures do we want to count on in the database?>
These don't always have objectively right/wrong answers but failure to ask the questions leads to poor use of databases regardless of what technologies are chosen.
On a side note, we also looked at MongoDB and, after running a few tests, we concluded that it is a glorified key-value pair storage. That said, we did use it in a few small-scale projects and it works great.
The bottom line: choose the right tool for the job and don't bitch about the tools when you fail.