I think the core of the difference can be found in the What exactly is meant by “the wrong abstraction”? paragraph. Admittedly, the quoted article is also a bit

I think the core of the difference can be found in the What exactly is meant by “the wrong abstraction”? paragraph. Admittedly, the quoted article is also a bit confusing here, but I think it's easy to resolve. I think the wisdom of the original saying is hard to understand when you just look at any piece of code as it exists. Instead, imagine the future. You have two pieces of code that do similar things - you can centralize them (with a bunch of conditionals) to have a "single" code path, or you can allow them to stay separate (perhaps confusing new people). The wisdom of "duplication is cheaper" is to observe that it will generally be less work to allow the duplication than to maintain the circumstantial needs over time. Each time you need to "do the same thing again but a little different" you can either add more conditionals to a single piece of code, or add another instance of 'duplication' which can just deal with the concerns at hand. It's not about "crappy code" - it's about the difficulty of having one piece of functionality serve many masters over time. IMO, in general, you will also find that if you have many 'duplicated' copies of code, it will often be easier to see the truly duplicated sub-sections that you can DRY out into a common subroutine. I find that is easier to see with duplicates than with a single piece of complex code.