I really don't like either "the rule of 3" or WET because I think they take the focus off the part of DRY that matters. It shouldn't be about syntactic repetition, but (as originally stated) about repetition of pieces of knowledge.
The focus on syntax misleads in two ways. First, it sometimes motivates consolidation of things that are merely coincidentally syntactically similar (pushing back on this is most of where WET and Ro3 are useful, when they are), which makes it harder to update the code when one "piece of knowledge" needs updating but not the other(s). If you have 10 things that all happen to be identical today, but any of them might change independently in any direction, combining them isn't "more DRY".
Second, the same piece of knowledge may be repeated in different syntax. If your setup means you have to say "there's a button here" one way in HTML, another way in JS, and another way in CSS, then combining those would be "more DRY" even though no syntax repeats. This isn't to say that combining those (say through code generation?) would necessarily be better - DRY is a guideline to be balanced against other guidelines; but I do assert that it is a more useful guideline when we think in terms of duplicated knowledge than in terms of duplicated syntax.
The problem I’ve seen with the “rule of 3” in real life is that by the time someone is writing a similar implementation by the third time, 5 years have passed and the entire team has rotated, so the programmer doesn’t have enough context to DRY anymore, and then the failed “big refactor that breaks corner cases” happens.
I find a mentality of _striving_ for DRY by default — even if end up choosing to duplicate for pragmatic reasons — to be beneficial in keeping programmers looking around for opportunities and refining the understanding of the context, with a better chance of incremental progress.
That's not a problem with "rule of 3", it's a more general problem: Misunderstanding these "rules" and "principles". Specifically, trying to treat them as absolutes. "We must repeat ourselves three times to comply with 'rule of three'." Well, no, that's silly. It's a heuristic, a guideline, not a law that can never be broken. If you spot a clear case of real duplication even before creating the duplication (easier with experience, either total or with the system under development), then you can clean it up earlier. If you can't see the duplication or are uncertain about the duplication ("Is this real duplication, or just coincidence? Am I going to change 90% of the code after all the modifications are done or just one value which could become a parameter?"), then go ahead and repeat yourself.
The same issue arises with YAGNI. People often jump too quickly to shouting YAGNI when the reality may be, and again this comes from experience-enabled judgment, that you are going to need it. "Don't make it a parameter, we aren't using it yet and don't know that we will." "But we do know, it's in the customer requirements that we don't hardcode the database server name everywhere, also it's just sensible."
These rules, principles, guidelines, laws, or whatever term gets assigned to them are there to help. They are not there to be excuses to stop thinking, but to provide a structure around thinking and a way to discuss with other people. But that structure is not absolute, experience and judgement can lead to breaking any of these rules at any time based on the present situation. That present situation that only you (and your team) know, but not the people who discovered, created, or coined the rules. They can only offer advice and guidance and not absolute instruction.
The focus on syntax misleads in two ways. First, it sometimes motivates consolidation of things that are merely coincidentally syntactically similar (pushing back on this is most of where WET and Ro3 are useful, when they are), which makes it harder to update the code when one "piece of knowledge" needs updating but not the other(s). If you have 10 things that all happen to be identical today, but any of them might change independently in any direction, combining them isn't "more DRY".
Second, the same piece of knowledge may be repeated in different syntax. If your setup means you have to say "there's a button here" one way in HTML, another way in JS, and another way in CSS, then combining those would be "more DRY" even though no syntax repeats. This isn't to say that combining those (say through code generation?) would necessarily be better - DRY is a guideline to be balanced against other guidelines; but I do assert that it is a more useful guideline when we think in terms of duplicated knowledge than in terms of duplicated syntax.