Earlier quoted context omitted.
I know it's a total pipe dream, but this is what makes me most sad about lisp never being taken seriously. It could have been common practice to create and pull in new language constructs like what this is doing.
Languages that rely on the user creating their own language constructs suffer from a balkanization of the language - each team creates their own language, and cannot share code. This is why D does not have a macro preprocessor.
One (slightly contrived) example is javascript's different (sub?) languages. JSX, await/async, typescript, pre-processors, etc.
It would be best practice to pull in popular versions of these things as opposed to rolling your own.
However, I also don't think there's much issue with some custom languages as part of a normal codebase when used in moderation.
There's not that much difference between using a traditional API that requires function calls in the right order, maybe some testing to ensure you're using it correctly, etc.
With a "new" language you can put a lot of that as static-typing style compile requirements. Essentially more guard rails to using a library correctly, and an opportunity to make a set of scoped primitives specific to what problem you're trying to solve. Ruby on rails is the best example of this sort of system.
Again though, I know it's a huge pipe dream, and for these ideas to go forward will require a LOT of change in our intuitions and methods of developing software. I'll never stop dreaming though ;)