Factor is an impressive piece of work for sure, but, in my opinion, like many "modern" derivatives of Forth it loses the major strength of Forth, brutal simplicity. It has drawbacks, but it also has advantages. Introducing new "modern" features to Forth adds complexity, changes this balance, and I doubt these hybrids will ever attract 'hardcode' Forth programmers or non-Forth programmers. At least traditional Forth systems are small and simple enough for someone to understand (I learned myself from a tiny Forth named PygmyForth, but there are many others); it provides you with a kit you can modify and customize at will once you've absorbed it.
The postfix notation even for conditionals is really not an issue when you dive into the language. However, with most systems you should be able to translate IF into 'nop', THEN into IF, and END into THEN and it should do the trick. But then there are DO WHILE loops. etc. But everyone prefers to preserve the postfix logic at the end of the day. It's like infix notation systems in Lisp and Scheme that never caught up (and, I believe, never will).
About your second point: most of the library code, in any language, looks like gibberish and like a mess of arbitrary idioms. One simply cannot hope to inspect and understand non trivial library code just just by casually reading it. With Forth the situation is indeed even worse, because implementers generally cannot resort to spaghetti code too much, whose continuous nature, at least, helps the casual reader.
On the topic of cooperative multithreading, I think that the trend in recent programming languages in general is that, nobody wants to deal with pre-emptive threads anymore. It hurts kitties, it is dirty. It is like manual dynamic memory management. Cooperative threads (if I'm not mistaken, they're also sometimes called "lightweight threads", "green threads" or "fibers"), avoid most of the problems of preemptive threads (because the programmer controls when execution can switch to another thread and when it should not very easily), while retaining some benefits (background execution of low priority tasks). For a "modern" Forth system, I think it could be interesting to keep cooperative threads at user level (really hardcore implementers may just remove them completely, because it is expected that the programmer may prefer to implement some sort of cooperative tasking fitted to his needs), and use preemptive/OS threads in library code (typically implemented in C).
Now that's the point of view of a 'hardcore' kind of hobbyist Forth user (and implementor). There is another category that finds brutal simplicity simply not practical and I can understand that. But really for educational/curiosity purposes I would recommend the hardcore way. Like, abandon all the bloat you're addicted to, shut the up, try hard and sincerely. I tried Forth this way because I was very sceptical when reading Moore (inventor of Forth) and Fox (one of his collaborator and friend; Moore isn't very good at communication, so Fox [RIP] was sort of his Plato) that their approach could work. These experiments in extreme simplification brought me a lot when I was a young programmer.