I strongly agree with the general principles you're putting forth, and agree it's hard to build an architectural philosophy which bakes in "good sense" as well. To some extent these can be orthogonal. (At the very least, your architectural philosophy had better not be opposing good sense, but I think it's fine for the philosophy to not encode every best-practice of good sense.)
> all look somewhat similar when done really well and thoughtfully, but tend to have different gotchas and failure modes.
I do agree with this to an extent, although I also think that "what does this theory tell me to do that differs from some other theory" is a quite valuable question; I do think there are some structural aspects of DDD which could be "bad" in other approaches.
Perhaps most obviously, the meta-approach of having well-known named concepts in your architectural framework is in some sense opposed to the "pragmatic design" or "framework-less" approach of just using good taste and experience to come up with the right design for each situation. The latter perhaps being "better" for experienced architects, but harder to teach IMO.
> when I think "Repository", I think a class with methods like "GetEmployee(employeeId)"
Not to beat a dead horse, but on this object-level point -- in my understanding DDD explicitly contemplates both singular fetches like `GetEmployee(employeeId)` and plural like `GetEmployees(createdAfter)`. I think the book (Evans, 2003) has examples of each (though I could be mis-remembering and drawing from some of the other practical DDD-by-example books).
But I can see where a team might use a sub-optimal combination of existing Repo queries rather than writing their own new ones.