When an inexperienced developer gets their hands on Design Patterns its not uncommon for them go wild and start implementing them exclusively, everywhere, and by the book. This can lead to complexity in situations that didn't require it or a lack of flexibility for new situations that aren't covered by existing design patterns.
Developers and architects might also ban certain practices in order to prevent newer developers from falling prey to specific circumstances. For example, banning all ternary operators because some less experienced developers may see them and make them more complex. If this line of logic is followed then we end up with coding standards that forbid compound criteria in if statements in favor of multiple levels of if statements or a series of if/elseif/elseif/elseif/elseif with repeating actions, or we have template engines that don't allow any logic in order to prevent designers and developers from 'accidentally' putting business logic in the frontend.
Knowing when something is okay, and accepting that someone is bound to try to break the rules until they're shown better, is part of designing a good application and mentoring new developers. If we always err our designs on the "but someone [else] might do it wrong!" then we end up with overly simplified applications that likely cause us more time and effort.