I haven't seen bugs due to DRY, but I've caused difficulty of adding new features and poor maintainability because of it.

When I first took over maintaining Red Moon, I was a very new dev and went a little DRY crazy. In particular, there's a state machine for the different filter states (running, paused, stopped, etc), that had a bunch of classes (one per state) that had a lot of overlap. I pulled some common behaviors out into a supertype that the classes with those behaviors now inherited from.

Except, it turns out some of those states ought to act differently (automatic pauses in secure apps should disable the overlay but not restore the backlight; manual pauses should do both), and now it's going to be extra work untangling the various states and pause logic. If I'd left the state machine (amongst other bits) as it was, this feature/bugfix would be implemented already. Also, the current state of things (pun intended) is a bit less readable, in my opinion.

I've seen people over-engineering a piece of code in order to make it "flexible" enough to be able to reuse it in like 2-3 scenarios that are not really well aligned - all in the name of making their code super DRY.

Sometimes it's better to have just a few separate, differently shaped pegs, than one flexible peg that fits any hole but is so complex that it might introduce 10 new bugs along the way.

I’ve seen plenty of DRY bugs due to premature abstraction and an unwillingness to refactor later on.

In many cases, the opportunity for DRY was misleading as the code was only superficially similar, so the implementation became over-complicated to handle various corner cases that otherwise wouldn’t have existed.