The truth is in the middle with better tooling to make it easier to design good code and get it working faster with fewer bugs even while at the bleeding edge.
A well designed solution doesn't feel like duct tape, nor should it be "too clever" with a crazy multiple-inheritance architecture that no one but the author can understand.
In fact, it sounds like the extremes described in this article are both crap developers, with different flavors of crap on the menu.
I insist on solid engineering. Nothing that feels like duct tape, but nothing that approaches over-engineering either. Easy to understand and easy to extend to the point of "OF COURSE this makes sense!"
It's not so much "in the middle" as "robust design vs one or another flavor of garbage." A strong designer is needed to get to that point, and maybe duct tape is better for shipping product than over-engineering, so if you HAVE to choose, the duct tape end of the spectrum is better. But even better to have a solid software architect who can come up with a good solution that people can use and extend and understand.
You're assuming that ductape == bad. What your describing is someone writing bad code, not someone gaffertaping a bunch of modules together to make the _more important_ code work. (instead of re-writing a whole bunch of things to make stuff more "idiomatic" )
This is where innovation tokens come in. You have one innovation token per project, you can spend it on the thing you actually need, or some pointless part of the system that you're bored with maintaining.
Mozilla and Firefox are better products. Many other solutions use their code (e.g. TOR).
All bets are off when competing against a monopolist.
Netscape maybe died because the technical debt forced them to bet the company on making a better product...which they did.