"XDD" for all X is overrated, in the sense that the ideas attract adherents who use them as the hammer for all nail-looking things. Yet the best way to present any XDD principles is to ignore the rest of the world and alternative approaches, otherwise you'll get bogged down in all the qualifications and exceptions and lose the central thread of what you're trying to communicate. The article is probably correct that b…
You need to understand the context that birthed DDD. It was a reaction to the model of building business logic into UI event handlers which was pushed hard at the time by the Visual Basic (and java equivalent) crowd in businesses. Originally Fowler documented the domain model in PoEAA, then Evans took the idea and ran with it. I agree that the book hasn't aged well: like the GoF book it's a slog to read. Evans isn't…
DDD was born from Eric's roots in Smalltalk development. When Smalltalk got supplanted by Java there was a strong desire to find ways of building Java systems that could recover at least some of that development style, such as domain modeling, despite the technology being less flexible. At the time it had sort of the feel of 'preserving what we can of civilization after the apocalypse'.
DDD wasn't the only thing that emerged from this. Other Smalltalk programmers became influential programming teachers in the post-Smalltalk world (Fowler, Beck, Cunningham). Eric was probably the last of these to emerge because he spent years working on his book. (It's been years since I've read it but my impression was always that it was unusually well written. It's true that you have to read it as a book to really get it, which is kind of a lot to ask nowadays.)