It is even entirely possible that this approach hits a middle-ground that serves the corporate software-development space better than highly-flexible languages.
The difficulty with high flexibility is that the expressions become very domain-specific very quickly, creating the challenge of learning the new abstractions. So one isn't just a LISP developer, one knows how to write in the specific forest of macros that have been built up around one specific problem domain. The end result is code that means nothing to a reader who doesn't have a dense forest of macro definitions in their brain (at least in this era, their IDE will likely helpfully pull up the macro definitions with a mouse-over or cursor-over gesture!).
Contrast with this approach, where the complexity of abstraction is being baked into the lower-flexibility language. The code is less dense, and that's a tradeoff... But grab any 10 developers off the street with experience in that language and have them read it and 8 of them will likely be able to tell you with some accuracy what the code is doing. Not a trick I've seen possible with even very experienced LISP developers on a codebase they've never seen before.
... and, of course, being able to grab a random 10 developers off the street and have 8 of them up-to-speed in no time at all is crack cocaine to big businesses with large and complex systems maintained by dozens, hundreds, or thousands of people.