The author complains about not having local variables, but most decent Forth environments have them. It is not difficult to have local variables in Forth, just use a library or compiler that provides them.
The language has, perhaps, a bit too much Chuck Moore: Don't reuse code, don't make code reusable, and don't try to anticipate anything. The knob is turned all the way over to the "simplicity of implementation" end of things, and all else be damned.
With regard to local variables, although standard Forth has them or considers them as an extension, Moore is correct in the sense that they are a crutch for when you did something wrong - often they allow to sweep under the carpet a "stack juggling" issue, which is usually a sign that you should reconsider your approach to the problem.
FYI Moore also designed processors; one of his designs was apparently viable enough to be part of the Rosetta mission. At some point he wrote his own CAD program to design his processors, which are at the very least functional.
It's not "simplicity of implementation" for the sake of it. It's about finding the simplest solution to a problem. But people too often confuse "simple" with "easy" if not "lazy" or "simplistic" - like your depiction of his approach.
Author here. I didn't have a decent Forth environment, I had a weird mess that I built myself from scratch. I ended up implementing a lot of "sophisticated" features - coroutines, cooperative multitasking, an interactive debugger - but I was never annoyed enough by the lack of locals to seriously contemplate spending the effort to build them, so I just didn't.
