This is a scary editorial, and the preceding comments are also scary.  Normalization is not some wonderful thought experiment that it can be nice to have, but it's not strictly speaking necessary.  It applies a mathematical rigor to the art and science of relational database development.  

Normalization through the third normal form is sufficient for most databases, and most sections of any database.  It is derelict of any database designer to suggest that normalization to this point is "optional."  The normal forms above that address specific cases that the first three normal forms do not adequately address.  That the editorial talked about sixth normal form is something to strive for is silly. This is to handle the use of time in a manner that was not foreseen at the time Codd laid out the original ground rules.  For all the database work that I've done, I have not had to deal with this.  So when I start creating a database, I don't think I've got to normalize this through six normal forms.  Three almost always suffices.  And frankly the rules are common sense.  If you have each fact in one place, you're probably there, or pretty close.

A database administrator's first duty is to protect the integrity of the data.  It is not to have the most performant database.  Six joins may be faster than ten, but if the design makes data errors possible, what's the point of going fast?  Is it better to return bad data fast, or good data a little slower?  The rules governing normalization provide the guide for carrying out this first duty.  They are ignored at your peril, and the peril of all those who will have to live with the design that you created.

My primary concern in expressing the counter view is that all too often when I've dealt with actual designers and designs, it seems that the resistance is an unwillingness to take on the rigor required.  And unfortunately I have had to live with the results.  Denormalization has it's place.  I have occasionally--and I stress occasionally--denormalized a portion of a design for performance reasons.  But that was after no other solution would work. 

As for OLAP designs, these normalization rules don't apply.  A different set of rules comes into play, such as granularity of fact tables.  These rules are also ignored at your own peril.  I got into BI because I was tasked to determine why the warehouse a consultant had created for us had some bad data.  After having read Ralph Kimball's book to give me some theoretical knowledge, I determined that he had not factored in this very important aspect of design.