Mostly that it's the simplest and oldest (and, in my opinion, the least "sandwiched in between five layers of indirection") version of a very common idea, that I'm not quite sure the name of. It's the idea behind DSLs, and Lisp-like languages. Most of Chuck Moore's writings on the potential behind Forth-like languages are also about this idea. The most modern instantiation of the idea, I believe, is "Behavior-Driven Development" with Cucumber et al. But it's all the same thing, in the end.
Generally, the idea is: first, you should define a language to directly express statements about your problem domain. Then, in one place, you can define the solution in terms of the problem domain. Completely separately to that, you can implement the mechanism by which a machine interprets and acts upon statements about the problem domain. Putting the two together results in a program that solves your problem. But either may be maintained separately.
The term "separation of concerns" has effectively always been about making sure that demands for change that come from separate "departments" don't end up touching the same line of code. This model excels in that: maintaining the specification of the solution is solely the province of the business, while maintaining the interpreter of that specification is solely the province of some engineers somewhere. As long as the interface between the two is stable—a stable ABI—improvements can be made to one or the other without the other group ever having to be aware.
A great example of this is the Inform 7 language. One group of people writes text adventures in this language, or enhancements and plugins for text-adventure development. A separate group of people maintains interactive-fiction interpreters that parse a given ISA. Neither group has to think about the other. The ecosystems of the IDE and the runtime are, in fact, completely divorced.