As a soccer referee, I have officiated games played by nine year-olds to "Over 40" and from barely skilled to very skilled. As a Data Analyst I work with both large and small databases. Each has its own different levels of "by the book" rule enforcement, if you will, and I think the analogy between the two provides sound commonsense guidance to data modelers.
In soccer, small fouls away from the action are often not called, and are considered trifling offenses that do not impact the game overall or interrupt the flow of the game. Conversely, in basketball or football every call is made, no matter its impact on the actual outcome of the play. Soccer even has the concept of "advantage", where material fouls are recognized, but play is not stopped and the foul is not penalized specifically because it would negatively impact the attacking team.
In a soccer game played by ten year olds at the recreational level, a firm shoulder charge where one child is knocked down is typically a foul. In an adult game, well, it might be a foul but often it's just part of a physical game and tolerated by the players. Knowing the difference and "what the game needs" is an art that sometimes takes a long time to learn. Allowing too much contact between young (and probably crying) children is just as bad as not allowing enough between aggressive young adults. Some of the biggest errors I have made as a referee have resulted from allowing too much, or not enough, physical contact based on the needs of that specific game.
So let's extend the analogy to Data Modeling. Many years ago I worked on a project involving product promotions and their associated codes. There were promotional sources and different levels of grouping and categorization. Many normalized tables were involved in the data model, and the complexity was high. This led to complicated joins, developer frustration and lots of questions among the analysts, programmers and modelers. Should the data model have been made simpler and easier to understand? What would have been the result if it had? Would the project have run smoother? Or hampered by unforeseen issues? Would we have had more crying players and angry parents, or more free-flowing play and few stoppages?
Just how "by the book" do we need to be with our data models? Third Normal Form? Fourth? How about Sixth? The answer lies somewhere in the middle, and is typically dependent on the project itself, best determined by "Art" rather than the "Science" of Data Modeling.
Is your application more transactional (inserts, updates), or used mostly for SELECT's? (What age groups and skill levels?)
Do we need to break things down into tables consisting of the lowest common denominator, or can we tolerate a few NULL's here and there to make things simpler? (Allow more contact or whistle small fouls?)
Does having fewer tables and thus fewer joins for complicated queries cause the application run more effectively? Or will this allow and encourage overloading and lack of extendibility and flexibility? (Does the game need more flowing play and few stoppages, or will players become upset with too much contact?).
Where is the balance between ease of use and "by the book" data model purity? The answer, like refereeing a soccer game, is determined by what's best for each project based on its specific needs and not strictly "by the book".