Reasonable people (including DDD advocates) clearly understand that tactical patterns can easily be misapplied, and that the strategic part of it is more important, but inexperienced programmers jump in on the "new" fad (it's not even that new, which is most perplexing to me), and misapply all the patterns they possibly can.

I see there's a lot of similar sentiment here, so I think the question really is: how to convince inexperienced "converts" where the right boundary of applying tactical DDD solutions is?

A. Don't learn things.

B. Dedicate some amount of time to learn something in a sandbox before using it on the job.

C. Once you've learned something well enough to see the error of your ways, dedicate some amount of time to clean up your old work.

B and C are a single thing, and unfortunately, C does not happen, which is why any particular methodology gets a bad rep. And it's obviously already happening with DDD (judging by the polarized sentiments around here).

And finally, while I do believe abstraction is the ultimate tool of the human mind (and mathematics is the purest form of abstraction we are capable of), I do not think it suits all brains equally, and not everybody will be equally capable of ever getting the right understanding. Basically, your architecture can be _too smart_ if you are looking to hire actual, real-world developers and software engineers, and have them be efficient.