Interesting subject, I don't think I agree but it's difficult to give a one-rule-fits-all in this scenario.
My initial thought is that your analogy for too clean is actually a fault in the design and perhaps a misuse of design patterns. As soon as code gets too complicated to understand it's an indication that you're not taking the correct approach.
Logically, if we're not designing code for readability and maintainability, what are we designing for?
I think we should first of all design for functionality, and to be able to deliver this functionality on a regular base, we should also focus on readability and maintainability. Code that is too clean can be a fault in design, it can also be the misuse of a design pattern, or a lot of things for that matter. And a lot depends on interpretation. If you'd ask me a while ago to define you what I think design patterns are, I would have said something like; Their proven solutions for reoccurring problems. This is translatable to, if you face this problem, use this pattern because it is the best way to solve it. If you'd ask me the same question now I'd say; Their proven solutions that could help you solve reoccurring problems. Do you see the subtle difference? What I want to say with this, and all the things we use as guidelines, best practices, how to's and what not, these should trigger your own thought process, not just tell you how to do it. Coming back to the rooms, you are living in the code base with several people, and you have to figure out what works best for all those people, not just implement what outsiders say, because they don't have to live there.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.