So I think you need to look at the following question Quora question:
How much credibility does the post "Don't use MongoDB" have?

Some people who talk about leaving MongoDB:

• Anonymous: http://pastebin.com/raw.php?i=FD3xe6Jt
• Zopyx: http://www.zopyx.de/blog/goodbye-mongodb
• Bump: http://devblog.bu.mp/from-mongodb-to-riak-7138
• Urban Airship: http://blog.schmichael.com/2011/11/05/failing-with-mongodb/
• Shareaholic: http://blog.shareaholic.com/2012/08/migrating-to-riak-at-shareaholic/
  
• DigiDoc: http://svs.io/post/31724990463/why-i-migrated-away-from-mongodb
• Etsy: talk about a project that failed to get off the ground with MongoDB
  Why MongoDB Never Worked Out at Etsy
  
• Aphyr's Talk: MongoDB 2.4.3 is not consistent, even in the mode where it should be. Here's a long post about it (Call me maybe: MongoDB). When we talk about product maturity & quality below, this is the exact type of issue that comes up. (another post from 2015: Call me maybe: MongoDB stale reads)
• Viber (the mobile message app): dropped their server load in half by moving to Membase: Viber Replaces MongoDB with Couchbase

Their arguments center around a few core themes:

1. Product Maturity: low QA quality, sub-systems repeatedly breaking, driver inconsistencies, scattered and incomplete documentation, complex node management.
2. Design Decisions: single write lock, memory-mapped files means that the server has little control over its performance, replication has no proxying causing ridiculous connection numbers, sharding is possible but very complex to implement b/c of several special nodes, sharding is unreliable, lots of pitfalls and gotchas.
3. Wrong Trade-Offs: in a few cases, people started using MongoDB without grasping some key difference between MongoDB and traditional RDBMS. Joins, audit trails, aggregation, schema management, queries into nested objects... MongoDB makes some things easy in exchange for extra work elsewhere, but it's not always clear what these trade-offs are.

I have worked with MongoDB in production settings for about 2+ years and am currently the #1 rated MongoDB person on Stackoverflow, so I have seen several of these limitations.
http://stackoverflow.com/tags/mongodb/topusers

The key thing to understand about MongoDB is that it's not a magic bullet. It has significant tradeoffs like everything else.

Instead, I think of MongoDB as a "twist" on a typical RDBMS. It's not a Dynamo DB, it's not a Bigtable DB, it's not a Key-Value DB. It's really a hybrid database with features from a few different places.

It has secondary indexes and complex queries like SQL DBs. It implements replication similar to an SQL DB. It has a Map/Reduce/Aggregation framework like a Big-Table DB. It has auto-sharding features that are halfway between some SQL implementations and Key-Value DBs.

It has strong consistency like DynamoDB or SimpleDB but it does not have MVCC (details http://blog.mongodb.org/post/523516007/on-distributed-consistency-part-6-consistency-chart). It has highly configurable write concerns front and center but the first two modes "fire & forget" and "safe" do not actually commit anything to the disk.

At the end of the day, MongoDB kind of lives in its own little niche. It makes a lot of unique trade-offs that must be understood to use it effectively.

Also what did they move to?

Generally something more specific to their goals.

• If you end up needing to run lots of Map/Reduce, you probably end up running Hadoop (or their new Hadoop plug-in). MongoDB is not designed to match the speed of Hadoop's Map/Reduce.
• If you shard heavily and only use Key/Value look-ups, then Riak is probably easier to manage on a large scale. In fact, the Bump post says exactly this: We decided to move to Riak because it offers better operational qualities than MongoDB...Nagios will email us instead of page us,...
  
• If you're using MongoDB heavily as a cache, maybe you end up using Membase / Redis / HBase.
• If you start using MongoDB as a Queue, you will eventually want to look at real queuing systems. RabbitMQ, ActiveMQ, ZeroMQ, etc.
• If you start using MongoDB to do search, you will eventually find that things like Solr & Sphinx are better suited to resolve the full spectrum of search queries.

The key here is that MongoDB is really a set of trade-offs. Many of the databases above are very specific in what they do. MongoDB is less specific but is serviceable for handling many different cases.

However, once you get to a certain scale, MongoDB will underperform the specialized solution. In fact, I'm seeing this at my day job where we are actively moving several sub-systems off MongoDB and onto better-suited products.

2015-09 Update: I think this link is a good summary of the MongoDB problems: Why you should never, ever, ever use MongoDB

It highlights a lot of what is discussed above. In 2015 MongoDB is really just a second-rate option.

Edit (2012-09-11): Added Shareaholic to the list. Reasons listed are similar to the above. Just another data point.

Edit (2012-09-17): Added digiDoc link.

Edit (2013-01-09): Added Etsy link, in their case it was definitely an ops issue around managing this new set of machines.

Edit (2013-05-24): Added Aphyr's talk about failure cases.

Edit (2014-03-05): Added Viber link: "MongoDB could not hold the throughput that we needed, we actually had to put a separate Redis cluster for some of the high-throughput needs that we had..."

Edit (2015-09-29): Added another link to another of Aphyr talks. And another "don't use MongoDB" link.