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).

The rest of your arguments are also similarly terrible which makes me question your familiarity with Forth.

Here is NASA using Forth:

https://www.forth.com/resources/space-applications/

It all depends on what words you want to define and whether they must operate on the stack or not.

Words do not have to always work from stack.

High complexity is entirely possible. I have seen that done too.

I can't agree with you there. In fact, Forth was originally conceived to control a telescope.

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).

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.

‘Slab allocation’ is an implementation strategy for a ‘normal’ memory allocator, where each block gets freed individually (https://en.wikipedia.org/wiki/Slab_allocation)

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.

That guy knows how to make Forth perform real time. He has a bit different take on how to build such a Forth.

Multicore too.

Why? I can't think of any reason that this would be the case.

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.