I suspect these different design "paradigms" all look somewhat similar when done really well and thoughtfully, but tend to have different gotchas and failure modes. Happy vs. unhappy families and all that. The worst design decisions we've seen are very salient in our minds, and these bad decisions are more shaped by the paradigm than the good ones are, so they look like the fault of the paradigm. Therefore we tend to compare paradigms based on how they go wrong, and people see bad design and think "wow we need a new paradigm". In that sense: YMMV indeed, and if DDD works for you, go for it. It's definitely worth learning, even if only so you can disagree with it! There are a lot of good smaller points in the DDD book even if you disagree with the larger paradigm.
As an example, when I think "Repository", I think a class with methods like "GetEmployee(employeeId)" that hit the database immediately, and probably call other GetSingleThing methods in other repositories, possibly in a loop. That's how you get SELECT N^2s and up. That is, of course, their worst possible use, and you can have much better-thought-out services and still call them "repositories".
That all being said, there are some near-universal "good ideas" I've learned, but they probably don't make a good textbook, and they certainly don't make a singular "paradigm" to follow. Things like: make decisions as late as possible (but no later). Do less, plan more ("do" meaning something with a side effect; planning is side-effect free). Work with sets instead of individuals. Separate identity from data. Raise the ceiling (empower smart people), not the floor (don't design for stupid people), but also realize that everyone is both sometimes. I use these general rules to evaluate paradigms, and I think DDD strongly fails the "make decisions as late as possible" rule, and doesn't tend to foster the "do less, plan more" rule unless you really reinterpret a lot of its directives.