In my opinion it's people problem. Lots of developers are focused on pure technicalities. They will focus on writing code and ignore why it's written.

As result of that their choice of architecture will be detached from business function. Also, as thinking about architecture isn't writing code it will be often afterthought based on shallow knowledge and superstitions.

Keeping that in mind - when you are talking to bigger team containing people with various seniority, it's often best to give them rigid set of rules, because they'll misinterpret or ignore something more complex.

And that's why black and white approach often works - it's far from ideal, but at least possible to actually execute in many of the teams.