My experience is that these companies have the worst kind of technical debt: a prematurely optimised and poorly abstracted codebase, due to non senior engineers refactoring just in case. Non abstracted codebases are boring to work with because the same code is duplicated, but they are not that difficult to change or add feature to. Extreme DRY on the other hand are the kind of codebase everyone is afraid to touch. Sure maybe they had 100% test coverage in their days, too bad adding a new feature with a small model change would break every interwined object factory.
It's not just extremely DRY stuff that can be problematic.
I work in a non-abstracted code base, but all that really means is every time someone wanted to do something they simply wrote their own way of doing it. Needless to say it's suboptimal to work in on the best of days.
People like to deride one way of doing things vs another but in reality pretty much every approach to software development and architecture can be amazing or hellish depending on the aggregate quality of the developers, their management and the lines of communication between them.
TL;DR - Bad code is bad no matter the paradigm and all paradigms can be made awful.
