>Sure, and everyone complaining about OO isn't doing OO right, and everyone complaining about scrum or agile hasn't actually experienced scrum and agile correctly.
There's a huge difference between OO/scrum/agile and the DRY principle. OO does not have a well defined origin and definition. Agile does, and is intentionally not well defined. Scrum does have an origin, but I bet if you read the original author's description of it, you'll find it also is not well specified. Pick any "No True Scotsman" argument and the root cause of all of them is the lack of a clear definition. That's simply not the case with DRY.
Furthermore, all these three are a lot more complicated than the DRY principle.
The DRY principle has an origin, and a well established meaning. If you go to its Wiki page, it's nice, concise, and precise. There's no real dispute about it. Generally, those accused of misusing it have never even read the definition, and are taking a concept they heard from an Nth degree source and are interpreting it by its name.
There are likely more people in the world who misuse the principles of quantum physics than those who use it and understand it properly. We don't criticize quantum physics for it. It is precise, and is not the cause of all its misuses.
The other problem I have about people criticizing the "overuse" of DRY: Had the DRY principle never been formulated, you would see no less of it. Coupling different requirements via a common code merely because the logic is identical is probably as old as programming itself. I myself was guilty of this (and bitten by it) long before I had heard of the DRY principle. Someone formulating the DRY principle did not exacerbate the problem. People creating these problems are mislabeling them because they've heard of the principle's name. My challenge to you: Whenever someone couples code in the name of DRY, ask them where they learned that they should do this. I doubt any of them will list any reputable book, for example.
Which again contrasts this with OO/scrum/agile, of which there are several books with quite different interpretations, and where one of the key annoyances is that everyone can back their stance using well known books.
Getting DRY right can be quite challenging in some projects - I'm not trying to claim otherwise. In fact, I believe the original authors were not speaking only of code, but also of documentation, databases, etc. One representation that will cover all of the above. It is clearly challenging to take it to that level. I'm all for criticizing it on those grounds. My complaint is that every criticism I've seen of it wasn't about how difficult it is to follow correctly, but about someone coupling two clearly different requirements with common code.