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