My tech niche is not a Big Shot Software Engineer™, so take my opinion with a grain of salt. Still, from my limited understanding, if in a very DRY project you get “brittle code where simple changes are scary because they could have a huge ripple effect”, what would be the alternative experience you would get in a, uh, humid project? Instead of “ok this one change overhauls an implicit assumption in every single part of the program” you get “ok this one change overhauls an implicit assumption in some parts of the program, and some other parts of the code might be making another implicit assumption incompatible with the first, and hey maybe these parts overlap, who knows”. Again, based on my limited understanding, trading the first scenario for the second does not seem that attractive a deal.

But really the true reason for my opinion is that once somewhere on the internet I saw someone oppose DRY principles using the slogan “Don’t DRY yourself out”, and the lame '90s PSA campaign energy inherent to that phrase infuriated me so much that I’ve supported DRY in software design ever since, out of pure spite. Behold – man, the most rational of all animals