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.
FORTH excels at control jobs and other embedded tasks.