Yeah, FORTH is really good at this. You can start exercising stuff at the hardware level in just a few hours. It's fantastic for system bring-up, and I've used it several times for this.
FORTH is terrible at scaling to large systems, though. It's also terrible at hard real-time tasks (like games) or anything requiring much in the way of data structures (FORTH's memory management is about as primitive as you can get).
I am not sure in which universe games can be described as hard real-time tasks but it's surely not the one we live in. Either way, it's laughable to say that Forth is terrible at hard real-time (see NASA link below).
The rest of your arguments are also similarly terrible which makes me question your familiarity with Forth.
The telescope application was not very demanding real-time. It basically did slewing control, and you have sufficient overhead to do that in BASIC; milliseconds don't matter very much. Telescopes are a classic example of FORTH's success; the problem comes when you try to extrapolate from that into other problem areas.
The attempts I've seen to make FORTH work in a real-time game have all ended in failure. There are technical reasons for this (high cost of inner interpreter overhead, lack of dynamic memory allocation, program structure that makes it difficult to work in large teams) as well as social ones (mostly lack of objective evaluation of quality, and other immature engineering practices).
Dynamic memory allocation seems like something you'd generally want to avoid in real-time programs and games. Slab allocation is often used (I think that's the right term, allocate a large chunk of memory at startup, bump a pointer to allocate, reset the pointer to free all memory at once), and that's simple to implement in Forth.
If inner interpreter overhead is an issue, there are well known solutions to that as well. Subroutine threading removes the inner interpreter entirely, and makes it simple to implement inlining in the compiler, and then there's always the inline assembly approach.
I'm using Forth for real-time data collection, and have been very pleased with it's speed. I'm able to reliably and consistently grab sensor readings over a 500 uS period with an average jitter below 1.2 uS on a Cortex M4. Yet I still get the flexibility of a dynamic language. It's a nice environment after the addition of some routines (coded in C) for dynamically allocated arrays with better safety mechanisms. In my case I'm not responding to various user inputs, etc, but the cost of the inner interpreter appears to be on par with - or better than - various bytecode interpreted languages.
”There are technical reasons for this (high cost of inner interpreter overhead, lack of dynamic memory allocation, program structure that makes it difficult to work in large teams)”
I think none of those have much to do with real time, per se.
Inner interpreter overhead may affect performance, but a real time game need not perform well.
Lack of dynamic memory allocation can’t be an issue, as one can always implement it in Forth.
I don’t contest that difficulty to work in large teams is an issue with Forth, but that doesn’t affect ability to write real-time games; it affects ability to write large/complex games.
Forth was used for a few commercial games in the 80's(e.g. Starflight), but game programming tends towards getting knee-deep in a statically allocated global state with a large, bespoken update procedure, both of which run contrary to Moore's preferred style of Forth(small word sizes, most things on the stack). So relative to macroassembers, the obvious competitor, most of the potential in Forth can't be usefully realized without reframing it as a metaprogramming tool that emits an assembler binary(In which case - you are going for high level abstraction. There are languages that give you lots of those without effort on your part.)
Forth does excel at low memory usage, but the gains are only realized when you don't have a static allocation driving things. Game scenes and most real-time code are statically allocated because statics will allow you to "deliver on what you promise" - if memory is maxed out, the system still hits its deadlines.
I guess what you are saying is that while forth is capable, it doesn't really give you anything over using assembler for low-level programming. And if you want high-level abstraction, you can always use C anyway.
FORTH is terrible at scaling to large systems, though. It's also terrible at hard real-time tasks (like games) or anything requiring much in the way of data structures (FORTH's memory management is about as primitive as you can get).