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.

Ah... simple back office crud coding. My favourite type of coding.

Of course, if your abstraction was an interface, you could just use a different implementation of the same interface.