'professional managers' might not know this.

right, this is an apples to oranges comparison.

you're comparing the feature that RDBs do best to the feature that NoSQL DBs do worst...

The most common use case for Mongo is storing relational data for web apps, and the most common outcome for those apps is complete dysfunction. How do I know that’s the most common use case? Aside from my own anecdotal experience, you just need look at the features those DBs implement. They’re constantly implementing new RDBMS-like and ACID-like features. They wouldn’t be doing that if that wasn’t their market. Why does this happen? Because people who don’t know better keep thinking that they can somehow work around the constraints, and just make a mongo (or dynamo) RDBMS work somehow. It is an apples to oranges comparison. But it’s worth making, because of the large number of people who think it’s ok to substitute oranges into apple pie recipes.

None of that matters because your data needs to be modeled around your application usage patterns. If you maintain inter-collection relationships via Joins in Mongo just as if you were in Postgres, you're not doing it right.

Your schema needs to be modelled around your domain, because that will dictate what your application usage patterns actually are. That will determine wether using a document database is feasible or not. If not, then there isn’t any design cleverness that can save you.

Like NoSQL proponent, never do that. Worst offender often beeing Mongo (although they calmed down a bit since "Web-scale" days ...)

And the corollary: if you store data, you need to use joins.

Embrace denormalization! It makes for splendid job security.

Not if you're just doing vanilla document storage.

this isn't always true there are plenty of schema designs for storing data based on your application's usage patterns.