Uncle Bob covers this by talking about how real duplicate code should change for the same reason. If the two pieces of code look the same, but from a business perspective can change for very different reasons then you have incidental duplication and should be treated separately.
I found this so often when I was doing simple back-office crud coding. There would be a new business use case that was very similar to something we already had coded. Code would be copied, since that's the easiest thing to do and you at least started with something that you knew was working.
Later, the new use case would evolve and have some new requirements. Had we abstracted the functionality originally, we'd have to go back and make the abstraction handle both cases. As it was, we could just change the copy that needed to change, and know that we weren't going to break the other case.
This was also before the practice of automated unit testing was well understood and supported by development tools, so the motivation to "not risk breaking working code" was much stronger than maybe it is today.
