Although I tend to agree with the author's sentiments here, there is one important distinction that ought to be made here: more features/capabilities != more code != more complexity.

In my experience developing both in net-new codebases in addition to large legacy codebases, there certainly are cases where better abstractions/paradigms equate to less code, and ultimately to less complexity. Yet at the same time, these improvements tend to yield more flexibility and capability, potentially providing additional features (sometimes entirely by chance). I find that in these such cases, it actually becomes easier to reason about what your code does, because you have come to a point where you can clearly generalize about your software.

On the flip-side, I can also greatly empathize with the author, as even in my attempts to generalize the functionality of software, there often exist ugly one-off bits of critical business logic that invariably dirty the water. In these such situations, it seems to become harder and more complex to build generic code, and you are much better off just sticking to the straightforward implementation without allowing for any of the bells-n-whistles that a more generalized approach might offer.

TL;DR--It really depends on the situation, in my opinion, but this shouldn't prevent you from trying to find a generic solution that is less complex yet offers more.

Many otherwise good developers I know struggle with this. The best way I've found to combat it is to pair with them during high-level design/dev, and code review early and often.

This works if you're in a position of power, but sadly even some senior and lead developers seem to struggle with it.

A colleague of mine likes to short cut a customer discussion about features by suggesting "We just add an option/tick box". He knows I hate him saying that but he feels happy everybody thinks he's found a solution. When infact he's just creating technical debt.

I distance myself from those that don't take my advice. It's easier on me.

In this case, would you refactor by removing only the components in the interface, or would you ask them to just delete everything extra wholesale?

There's an acronym for this: YAGNI

You Ain't Gonna Need It.

How has no one yet shunned the author for writing poor documentation. Sure you can just throw the code away but ultimately his time was wasted. He probably wants to keep it for the next time they write poor documentation that actually does need that feature.

Couldn't agree with this more. So many developers I know let sunk costs influence their actions and it stifles their ability to innovate.