It's a trade. For example, you can split the whole program (think execution of hundreds of business rules) into an interpreter - maintained by developers - and the pure rules in an easy to understand text file - maintained by business people.
Has that happened, pretty much ever? It is a great aspirational goal. I've never seen it pan out, though.
Not that there isn't a benefit from reducing things to the language you use to reason about the overall problem, and the language used to implement it. In large, whether you create a "DSL" or not, you almost always move to doing things in terms of the API you are using. Effectively making it a language. Taking a little more deliberate control does seem nice.
That said, I have found benefit in keeping fewer abstractions around. This is especially true as I am supporting an API. Don't hide that API from anything you do. Too easy to hide warts in it that you might otherwise fix.
Almost every story about a "business rules engine" I've heard was that it eventually turned into an odd Turing-complete programming language, and it'd be simpler to just write the same code in the original language.
