Most definitely depends on use cases AND common sense.  Take 1NF.  It seems we can always divide something into even smaller units.  A street address has a number, street name, and suffix such as RD, AVE, BLVD, etc.  There can also be a compass direction.  E.g., 3704 E. Main St.  But, why would we ever want to break the street address up into these smaller parts?  We almost never want to query on these parts (Give me a count of addresses grouped by suffix?).  Even a simple string can be broken up into words, then letters, and even vowels, consonants, etc.   But it would be absurd to design a database this way.  

Conversely, we can go too far the other way, as this post pointed out.  I'm currently working for a company that recently moved off a Main Frame computer.  Everything is now in SQL Server.  For the younger folks, Main Frame architecture was largely file based.  Step one was to move the architecture to the new technology.   JCL became Windows .bat files, COBOL became machine generated Java, and the Adabase/File system was translated, as best they could, into a relational database.  But relational in name only.  As these projects go, we never got to step 2.  Step 2 would have been reworking the architecture into a relational model.  Of course, the original Main Frame/COBOL developers remained and continued maintaining the system with little knowledge of relational modeling principles.  We have many tables with 100-200+ columns.  It's truly genius how they got everything to work.  But very inefficient.  I work in BI building data warehouses and creating reports.  I can often, with a few lines of SQL, recreate a legacy report that took a dozen flat files, even more JCL batch files, and 5-10 COBOL "programs".  I just finished one that can be run, on demand, in less that 15 seconds.  The previous version was run weekly because it took almost 3 and a half hours.  This is not an isolated horror story.  Many companies are in the same boat.  It is a testament to the power of a properly designed relational model.