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.
This works if you're in a position of power, but sadly even some senior and lead developers seem to struggle with it.
I distance myself from those that don't take my advice. It's easier on me.
You Ain't Gonna Need It.
