FORTH has one serious problem. Like your friend said, "Not everyone can handle" it. In organizations that hire programmers based on buzzword compliance and cost, it's only natural all FORTH code would be rewritten in something more... popular. It's true FORTH successes are most visible in not very visible niches. There was a time every Sun and Apple computer came with a FORTH interpreter in ROM and most SPARC-based servers probably still do.
The biggest problem is that FORTH seems to be a 'loner' language, I've yet to see it be used efficiently by a team of any size. It's always one guy. And that one guy will make or break the project.
I believe that this stems from Forth being imperative (which is hard to handle itself) and that main control is done using two global structures (data and return stack).
You have two very very global variables to arrange your control flow.
Nothing is pure and everything can affect anything. It is very hard to reason and to draw borders.
That's misrepresenting FORTH considerably I think. The data available to a forth primitive is typically on the top of the stack. That's just the same in every other language, it's just a parameter passing convention that most languages share. The problems with trying to write image processing code with FORTH is that pushing an image on the stack or modifying it in place somewhere in memory is a bad match with the language primitives. So you then have to do a whole pile of plumbing to abstract out that little detail.
FORTH excels at control jobs and other embedded tasks.
I've found that forth works best when you use it to create a DSL for your problem domain, and you write your application code in that DSL. That DSL becomes the critical abstraction that helps prevent your codebase from becoming an unusable/unmaintainable mess. This isn't a new idea; the book that got me thinking about when/how to use forth was (oddly enough) http://thinking-forth.sourceforge.net/ . It's a good read even if you never intend to build a forth project.
As a side note, I've done image processing with forth: I helped build a commercial HD video camera with it that shipped in the mid 2000s, and I found it well suited once we had the problem reasoned out well enough to build our DSL. Overall the product ended up being composed of forth/C/hand written assembly, and a bunch FPGAs. We shipped things with < 10 people, and I think the interactive/extensible mindset that forth gave us helped us get the product out the door successfully.
Oh, man, is this ever the problem with Forth: the absolute delusion, ruthlessly reiterated by Moore and the Faithful(Forthful?) that the only reason Forth hasn't taken over the world is that everyone other than the Faithful are too stupid to get Forth and see how completely superior it is to everything else. The only time I ever said "Forth rocks!" is how easy it made getting through those college "design a computer and a usable programming environment" classes, because a dead simple stack based arch + Forth gets you a solid C.
There was a time every Sun and Apple computer came with a FORTH interpreter in ROM
And there's a reason they don't any more. It was a pretty interesting way of enumerating device capabilities, and a terrible way of abstracting device driver details, which was why it was there. Having tried to beat Sun OpenFirmware Forth into making SBus device drivers "easier", I guess I fall into the "too dumb" category, because it was a disaster.
It is a beautiful language, if you can handle it.