It seems that the author's focus is on how things can become needlessly complicated, even when trying to implement a seemingly simple feature. However, citing only a few examples is not sufficient evidence. Could we not also consider instances where writing additional code could actually help reducing long-term technical costs?
Aside from this, I found the following points interesting:
> A technique for reducing technical debt when adding a new feature is to work within the constraints of existing assumptions, rather than adding new ones.
> Even when it becomes apparent after the fact that the feature isn’t performing as well as we anticipated, the typical approach is to do nothing. Part of this is the sunk cost fallacy. Often there is the hope that even if the feature isn’t used today, it will be in the future. But there’s also a legitimate reason for doing nothing. Removing a feature also has a cost, both in the development effort needed to cleanly remove it, and in potentially upsetting customers. So once a feature is added to a product, it is almost always there to stay.