If I make an assembler in Lisp, compile it and ship it to you so that you can apply it to your assembly language programs, it wouldn't work so well for me to be diagnosing your assembly language problems in my compile time.
I'd prefer a language where I don't have to write a domain language from scratch and write a program that can enforce its rules at runtime. Rather I'd like to be able to express my domain code in the language itself, so that my users don't have to learn (and I don't have to create) a new language. That requires a consistent way of restricting things at compile time, which is very hard to retrofit - if I ever want to be able to enforce that programs don't do certain things, the language needs to not offer unrestricted access to those things.
If you express your domain code in the language yourself, users still have to learn and understand what you have done.
What you write in a language has its own de facto language, whether you capture its conventions in a notation or not.
Simply knowing the elements of the language in which that work is done isn't enough. Otherwise you could just memorize a language reference manual and call yourself a software engineer.
Or could just argue that since the program in any modern language is written in UTF-8, and the users know that already, they have nothing to learn.
There are still things to learn, and you may still need to adapt tools, but it's a lot easier to work with an "embedded" DSL than an "external" one. You still need to define the nouns and verbs of your domain, but you don't have to define a whole new grammar.
