My bigger problem with read other people's Forth is that no two Forths are the same. The language itself isn't really the problem. It is that you can only approach someone else's Forth code bottom-up otherwise you just don't understand at all what is going on. Most other languages allow you to dive in from the top, learn as much abstraction as required to get the job done and then you can move on.
I was famous at IBM for the quip: "The good news about FORTH is you can use it to write your own DSLs to model the problem you're working on. The bad news is the person down the hall already has." But we still used a metric butt-load of FORTH for board bring-up and firmware.
But more to your point. FORTH was used in a time when the predominant mode of coding was to construct more complex programs from less complex programs, so application developers usually got their hands dirty with some lower level aspects. That is... the application programmers chose the lower level abstractions they wanted to use. Now that we're beyond that and have, as an industry, decided that van Rossom and Latner are the only people who are allowed to define low-level abstractions, it's a lot harder to do that.
(Again, file this one under "old man yells at cloud.")
[2nd edit]
Maybe it's best to think of FORTH as a DSL construction kit. Lisp is kinda-sorta the same way. As you point out, it's super easy for someone to develop DSLs that require coders to understand not only their application domain, but also how the language and it's underlying hardware abstractions operate. And when you're using someone else's DSL, you have to understand how they thought about the problem domain. And we stopped teaching how to analyze that in the 80s.
Yes, for bringup it is a very nice tool. Just enough, not too much. I used it for a 68K board in exactly that role.