On the flip side... joins are expensive... I worked on an application, where presenting a single page, representing a single item in the application (classifieds site) required upwards of around 40 joins (iirc 36 or 46, I don't remember)... under load (including search result pages), the app was crushed by its' own weight.

I think the bigger issue is that people are afraid of separating data at clear boundaries, so long as the orchestration is in place. Having definitive data in SQL, and having denormalized documents in elasticsearch/mongo/rethinkdb works very well... other instances (huge read and/or write throughput) may work better in a Cassandra (or other bigtable solution) with application-generated lookup tables may be better. It just depends on your need.

With better support for JSON/XML nested structures and indexes in sql rdbms, it's becoming less of an issue for a lot of types of data/documents.