It can work if you think carefully about module boundaries so that the dsls do not leak out of their containing scope. Most of the time, dsls are not well bounded and even if they are, they are likely to confuse newcomers to the codebase. Of course, whether or not dsls are used, every program does have custom dsls in the form of functions that newcomers also aren't going to understand so it isn't as though programs written in a vanilla host language don't have many of the same comprehensibility problems as those written in a dsl.

That being said, not every piece of code needs to be accessible to everyone. Dsls allow you to create a hermetic world inside of a programming environment in which certain properties always hold, even if the environment does not guarantee these things for you. Programs written in the right dsl can be more productive to write and have much lower overall operational costs. But the price is that the rules of the dsl are not necessarily the same as the rules of the host language and this leads to confusion. For the truly ambitious programmer, it can be worth sacrificing accessibility to the median coder to build systems that the median coder can't even conceive of. Of course your reward is to be derided for not expressing the solution in a language they can already understand.

Wrt to Forth itself, Chuck Moore has pointed out that Forth is a multiplier: it makes good programmers better and bad programmers worse. I personally care more about the former property and frankly don't want to work with bad programmers anyway.