like many older developers, I have become less ideological about DRY over time, particularly as I have seen it motivate extremely abstract solutions that have proven difficult to understand and maintain
i have coined the term "Locality of Behavior" (LoB) as a competing design principle to DRY (as well as Separation of Concerns, SoC) that advocates more inlining of (potentially repetitive) logic in the interest of code maintenance and understandability:
Why does the "does it actually work" go down over time? I would expect to be the other way round: more experience, more chances your software "actually works", even if it's not following strict rules anymore.
There are multiple metrics to describe what “works” even means. You are right that battle tested code can be more stable and fulfill its goals more than new untested code or code written without a customer. At the same time it’s also true that any sizeable codebase, especially production code, will accumulate bugs over time, will almost always slow down over time, and will eventually once large enough become crufty and smelly and unfactorable and difficult and, maybe most importantly, expensive to maintain. Big systems are hard.
Why? There is absolute no correlation between readability and working status. It might be obfuscated code that works perfectly, or it might be obfuscated code that explodes every 2 days. And it might be perfectly clear code badly implementing a business need or implementing it perfectly.