Last year's Advent of Code I dived into Forth a bit (used GForth). Solved 5 puzzles in it, but then I got stuck, when I was reading in the input of a puzzle and the lines in the file were of varying length. I did not find a way to properly clear the previous line buffer and got wrong results because it still contained characters from an earlier longer line. I asked around for a solution but did not get anything helpful that always works. I think more time would be needed to truly get good at it. Learning some patterns that are typically used in the language to do things like reading a file line by line and processing it. Some string related stuff is supposed to become better in GForth soon, when 1.0 is released. Good to know!
That said, I did enjoy it sort of, until I got stuck. Sometimes definitions can be very succinct and it made me think about implicit arguments vs explicit arguments to functions. In Forth all is implicitly on the stack. It has to be there already, when you utter a word, otherwise you are making a mistake. That is of course harder to program correctly, but makes code very short. Also gets you naturally into the territory of higher order functions and point-free style.
What I think could be an issue with existing programs is, that one needs to build and memorize a mental model of all the implicit arguments words take. It adds one more lookup to the definition of a word. But perhaps this is a tradeoff for very readable code (if written very well, very well factored).
I also thought about "How could this ever do multicore?" and "How can any data structure be better than linear time, if everything is on a stack?". GForth seems to have stuff for making threads, but I have not gone that far on my journey.
Just try it. It is an interesting experience.