> Normalization for high volume insert/update transaction requirements (faster writes). Denormalization for (faster reads), typically used for data warehouses and reporting.

Normalization also better supports ad hoc inquiries and reporting compared to denormalization; denormalization is an optimization for regularized reporting patterns (responding to a question that a denormalized reporting design didn't anticipate often requires effectively renormalizing the data, which recovers the logical benefits of normalization, at a potentially very high performance cost.)

> NoSQL is designed to support both of these scenarios well.

Without the integrity benefits of normalization on updates, and without the benefits of normalization for ad hoc queries.

OTOH, there are very few uses of normalized RDBMSs where only the write performance benefits are sought -- usually at least integrity is a concern, and sometimes ad hoc querying as well.

Not being optimized for a particular use case, makes it a poor choice for anything outside toy, or best case, medium sized applications.

The point is you have the level of control that lets you optimize for your use case. RDBMSes are a jack-of-all-trades solution and have the advantage of needing very little customization, but they can't be as well-optimized for specific use cases.