I think it can work but it takes a different way of looking at things. The main thing is that you need to take the time to design that DSL from the start and stick to it, if you come to a place where the DSL can not do what you want you need to address the issue with the DSL instead of just falling back onto the underlying Forth. It is a very different way to program and at times you find yourself have to make massive changes to the DSL you designed which also means changes to the program you are using it to write.

DSL is probably not quite the right word, it could be but generally I think it is still going to be fairly Forth like, but you need to think of it that way. You layout what your program does and then reduce it to a few dozen words which work as a description language for the program, then maybe a 100 more words which those words require along with any glue and together all constitute a reasonably sane language. Then you start from the bottom up and implement all those words. The big trick is having the foresight required to pick the function of each of those hundred odd words well enough that no one will ever have to dig into the the 1000 odd words below that it took to implement them. It really forces you to think about how your program may evolve and the bugs which may crop up, you can't change one of those low level words without affecting all that are built on it and if you do the easy work around things start to get messy.

Not sure how well I explained that, I am no Forth expert but I am getting better.