The problem that highlights is both a process and an experience problem. It indicates that he did not have a clear picture of the development road-map for the project, which suggests there are silos of information. There were a lot of hints about this actually. The lack of code reviews (that's where the original dev's opportunity for quality improvement should have been caught and addressed), the fact that a manager would chastise him for trying to improve code quality and the fact that he made poor design choices when trying to improve said quality really does point to a dysfunctional process.

Pointing the finger at code quality here is failing to understand the difference between the trees and the forest.

I've had joyful experience of working with duplicate code that spanned over multiple thousands of lines. I still fondly remember a PHP script generating multiple xml files, supporting different versions of format. (It was an e-commerce format for exporting and exchanging products data). And with multiple inconsistencies among this copy-pasta that have accumulated over time.

The problem here is the boiling frog syndrome. Duplication rarely starts with thousands of lines. It grows over time, and the longer you put up with it, the harder it becomes to roll it back. But as long as it grows slowly, the frog feels comfortable.

Clean code approach may get overzealous, the potential for fanaticism may even be sort of inherent to this approach (I agree), but it stems for acknowledging this simple, sad truth. The truth is that complexity of naive code is kind of like cancer. If you don't detect it before it actually begins to hurt, it's not great news.