A whopping six joins?! Really?! Omg, save the whales now before it's too late.
Seriously, six joins isn't a big deal, and unless you have multiple millions of people networking in your site, your database shouldn't be dying with the model you describe. Someone f*ed up somewhere, and it has nothing to do with normalization.
You're missing the HUGE costs to de-normalized data on large dataset updates. You have to update multiple places every time data changes. For large datasets this can be disastrous, especially when you have to update objects as a single unit (or roll them all back). As these updates increase, locks increase, which then slows down everything else. You're seriously discussing running cron jobs to clean up the mess you are creating, rather than just writing clean code the first time.
If your only course to improve performance was denormalization, then you either have a pretty rare situation, or you need new architects and/or DBA's. I've worked at three companies now where developers lack of knowledge concerning databases and data relationships brought applications to a halt. It comes repeatedly from a developers centrist view of applications where their part is always the most important component and everything exists to serve their application. After than comes an over-reliance on data layer generators, which cannot optimize queries as well as a good DBA. So basically the developers make cuts to save time, misuse the data model, then blame the DBA when things go wrong.
Out of curiosity, did you find your DBA and Developers often arguing over where things should go? Every time I've seen the behavior, it's been because DBA's feel they cannot trust the developers to intelligently access data, either due to the current team, or that DBA's past experiences.
Every time I see a post like this on a blog I try to imagine it in Nuclear Engineering. Do you find yourself putting needless safeguards in your nuclear generators just because some professor told you to? They cost too much! Remove them! Don't do things by reflex! Every engineer should just do what works for them! Don't let standards get in the way of progress and performance!
I find it humorous, that people follow a million rules such as table names should be plural as a doctrine, then casually discard good design at the first hint of an actual challenge. To be fair, naming tables is fairly easy, and you rarely find that table names stump a developer and cause them to look for problems.