Sorry, I guess, that you haven't heard of teams caching denormalized data in MongoDB...

MongoDB uses memory-mapped files across all available memory to manage data, it sacrifices ACID for speed, and its capped collections sacrifice undefined size for more speed. Its client drivers originally defaulted to fire-and-forget semantics, emphasizing its performance-oriented design. Such performance orientation is suitable for cache or cache-like needs. The general point is that its place in a system is different than that of the typical "database", whether it's SQL/RDBMS, ACID-compliant, or even document.

I'm fully aware of the MongoDB's trough of disillusionment status in the community hype cycle. 10gen brought this on by setting unrealistic expectations early on, through poor documentation and marketing. Calling it a database, a term laden in the mind of the professional developer with expectations of ACID compliance and proprietary languages, was a shortcut that ignored its atypical performance-first roots, and all of the trade-offs that followed from that. I've read more comments from people with a lack or faulty understanding of MongoDB to surmise that it's stalled in the trough because the name confuses developers. "In-memory cache with persistence" is a also shortcut, but one that is a little more circuitous and strikes a better balance.