But if the stuff that needs to change is abstracted, it only has to change in one place. IMO, the point of "prefer duplication over the wrong abstraction" is t

But if the stuff that needs to change is abstracted, it only has to change in one place. IMO, the point of "prefer duplication over the wrong abstraction" is that "all the stuff that needs to change" is a partially-to-totally unknown quantity. You can either guess at the time you have the minimum possible amount of knowledge (when the code is initially written) or wait and make that decision later with more evidence. Even good tests won't save you from premature abstractions with the seams in the wrong places when a change request that cuts across them comes in; they will help as you try to disentangle multiple use cases that go through the same code paths that now need to be different, but it's still a mess. Or worse - you might not disentangle them, and wind up with "generic" code littered with 'if special_case' fragments.