I take your point that it is not perfect but it is simpler than factoring where named data is required.
My experience is that when it doesn't work, it might indicate that the code is fighting with how Forth is easiest to use.
I try to use Forth per Chuck Moore's philosophy and use many small definitions. This makes the code more like functional programming such that even data is handled by code snippets. When I get this right, factoring becomes trivial.
The trade off made for not having to deal with getting the parameters named, etc... is that if you're off by 1 anywhere in the number of parameters, everything blows up, which is why Forth is hard to write big systems in.
For sure feeding wrong args to a function is never good.
Experienced Forth users seldom have that particular argument count problem but all the other mistakes in programming are on the table. There is no free lunch.
The Forth coding process involves using interactive testing of your code as you write it. Every variable, constant, data-structure and sub-routine can be easily verified at the interpreter. And... given what you said it is advisable to do it. :)
ANS Forth supports local variables for those times when "stackrobatics" might make you crazy.
Although small, the Forth community has made good progress in this alternative way to code. Some of the newer concatenitive languages working with a clean slate have gone farther in improving the programmer interface. Forth remains at its core close to the metal.
My experience is that when it doesn't work, it might indicate that the code is fighting with how Forth is easiest to use.
I try to use Forth per Chuck Moore's philosophy and use many small definitions. This makes the code more like functional programming such that even data is handled by code snippets. When I get this right, factoring becomes trivial.