Having written a Forth-like native-code compiler (https://github.com/kragen/stoneknifeforth) and also a game in Gforth, I can't claim to be a Forth expert, but I agree. A lot of the weaknesses of the language (such as no compile-time checking of even the number of arguments to a subroutine, much less their types, and its terseness) are shored up by the interactivity of the environment. Some of the short words in Forth like ? only make sense in that context. And some things that might otherwise be weaknesses, like variables being static, become strengths in that context. (If you store into x in a word you're testing, you can see what got stored there with x ?.)

More generally, Forth, considered as a programming language, is not very good compared to other languages of a similar level, such as C or assembly. Its strength is as an interactive environment. (And none of what I've said here implies that you have to use a block editor.)

This is all fairly abstract, but it's not the first time I've talked about it, so I did an ASCIIcast last year demonstrating me writing a square root subroutine: https://asciinema.org/a/621404 I screwed it up in the middle and had to debug it, which is where Forth's interactivity shines. You may want to watch it on double speed, though. You can also get the pleasure of watching me learn that Gforth has readline-like command-line history!

That said, I think you're exaggerating a bit. I haven't seen a Forth compiler that's only a few hundred bytes, and I don't think the blocking PIO in Chuck's IDE driver is a good way to access an IDE disk, although it's adequate for initial bootstrapping.

I think it's ok to edit forth code in a modern text editor. Following your definition, many modern forth engines wouldn't qualify as a forth. You don't need an antique screen-based editor to get immediate words.

Another thing of the Forth spirit is that the system is supposed to be fully bootstraped (like most Lisps as well), having a very small of words written in Assembly, and then everything else fully bootstraped in Forth and available for customisation.

I agree. The tokenizer in the article completely misses the point of how Forth works: the tokenization is supposed to be driven by the words themselves, i.e. ." is looking for a " delimiter, ( is looking for a ).

Not to mention that the rest of the compiler also misses the point of how Forth works. This compiles a fixed subset of Forth and entirely misses out on the extensibility of the language.