Making persuasive arguments about subtle topics
When I make a persuasive argument, I want to boil things down to the simplest essence, so we can easily see one thing is better than another. For a complex beast like programming, that is made much harder. Each choice involves subtlety and context. "Some things are marginally better than another, and only in certain cases, depending" rarely compels.
The benefit of a particular approach may merely be ease of understanding, or ease of use. These are some of the hardest arguments to make with less-experienced and young developers, because young developers are often fast-thinking with great powers of recollection. Additionally, less-experienced developers may actively seek out complexity, conflating it with sophistication. It is not unlikely that when experienced developers raise these topics as a concern, they see them as a challenge to be overcome by their intellect.
It is difficult to make these cases because the less experienced have a simpler, more binary view of their world: DRY (Don't Repeat Yourself) must be applied in all cases. Always protect class properties with a getter and setter. Never use goto. Make everything as generic and abstract as possible.
There are numerous books, articles, and speakers promoting these simpler approaches. Audiences favor simpler, straightforward advice. All too often, recipients of this advice choose to take it as religious doctrine. It is understandable. In the complex world we inhabit, it is comforting to work with a smaller set of clear choices that many people share. This, however, prevents having the necessary versatility to create a human-oriented software.
"Thus, programs must be written for people to read, and only incidentally for machines to execute" -- from preface of "Structure and Interpretation of Computer Programs"
As an older developer, I have seen the consequences of systems that are built with an allowance for unnecessary complexity. Sometimes the bill does not arrive for a long time - months or years. But it always does, contributing to the overall grinding state of the industry. If you don't take care of these things as you go, you get to the state that John Gall alludes to in the famous "Gall's law":
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.