I work with Mongo daily, as well as MSSQL and MySQL and it's really just a question of understanding the strengths and weaknesses of each technology. Mongo is a less mature technology, in terms of the database itself, and supporting tools, but even more so in terms of developer understanding. Developers have spent decades writing to data stores (RDBMS) that had built in guarantees of data quality and consistency that they didn't have to think about much. The headache of mapping objects to normalized tables encapsulated the challenges of keeping the data consistent.
In mongo (or other document centered db's) you have to think about these problems up front. That's the new headache. You will denormalize. You will probably have to denormalize more than you planned to support different use cases. User centric versus feed centric in the linked article. And you need to plan how you are going to keep these in sync. If you need 100% referential integrity, then mongo et al are probably not your best choice. If you can deal with somewhat dirty data and performance or shardability are more important to your application, then mongo may be a better fit.
The real gotcha that I see is that often these choices aren't being driven by a rigorous look at the pro's and cons, but instead by engineering fashion. And that's when mistakes happen.