Forth was available for many of the microcomputers (and some minis) that could be called personal computers when they shipped. Engineers often constructed small Forth Kernels as the engineering department's debugging monitor for new hardware (including many things not PC), and, depending on the culture of the people they were working for, they often made their work available in the early users groups.
Non-engineers often did not know what do with Forth interpreters, and passed over them looking for BASIC.
Also, managers who didn't understand Forth would not allow the engineering debugging monitor to ship in the product, arranging for a conventional one to ship with the hardware instead. Managers who did understand Forth also took it out, to avoid giving the customers too much for their money.
Now, Forth kernels were useful as post-fix integer calculators, but you really wanted a much more complete development environment. That is part of what drove the creation of the fig-Forths -- helping to demonstrate a common set of definitions that could be used, with minimal porting, to construct a full IDE. (Line editor IDEs were still useful back then because we hadn't been spoiled by full-screen editors.)
Reasons Forth did not catch on? It didn't really lose its popularity, it was just totally eclipsed by the Bill Gates machine.
I think there may have been deliberate misinformation, because some thought Forth would not bring the customers back for the add-ons, etc. Gotta have that business plan that guarantees a cash flow.
But there was also a lot of terminology difference. Today we can describe a Forth as an interactive symbol table with fundamental math libraries. The detail of the split stack doesn't even hit radar level any more. It should, because of the now-well-known problems of the stack crash/smash, but I'm not willing to predict that common sense will prevail, even now. (Especially now.)
The terminology and concept differences were deadly.
"Instruction threading" is generating a list of mixed effective op-codes and procedure calls in a virtual machine that cached the return address to reduce call overhead. But people interested in Forth got all tangled up in details of the threading and wasted a lot of time in work that was mostly theoretical exercises in the limits of call optimization and pre-optimized static register usage patterns. It is actually valuable in an academic sense or in a CPU architecture research environment, but it didn't push product out the door, and sometimes made enemies that didn't need to be made.
(I was one of those who wasted considerable time on that.)
"Words" vs. functions/procedures was another terminology difference which was confusing. "Dual stack" was another. I think a better term now would be "split stack".
Postfix notation is a conceptual gap. You could (and some did) write a prefix or infix interpreter for Forths, but that mostly raised hackles. Other purist issues came up about the use of the stack -- whether to limit direct access to the swap/rot range or allow a generalized pick that could pull in operands from arbitrary depth.
Splitting the stack made post-fix natural and simple to implement in the interpreter, but there was really no real reason to avoid infix or prefix. Shoot, the standard word for defining functions is prefix in standard Forth.
The funny thing is that the non-Forth community has wasted a lot of effort support something called a stack frame that is mostly there to give the interleaved stack enough structure that you can safely use the interleaved stack to hold variables. With the split stack, all of the complexity of the stack frame goes away. If you really want a stack frame, it's just pushing the parameter stack pointer with the instruction pointer. The frame pointer can actually be just thrown away on return in most run-times if the stack is split.
And the other funny thing is that the split stack is still ignored as the primary first step in really dealing with the security problems of stack corruption. If you don't want the return address overwritten, don't store it with the parameters and variables.
The 64K boundary was another point of conflict in concepts. In other languages it was not such a big issue, but many early Forths made use of the 16 bit modularity, and there were some purist arguments about that, as well.
Considering the size of a bit-mapped display frame buffer, no one should ever have taken the 64K arguments seriously, but hind-sight is twenty-twenty.
That brings up one more sticking point, which you refer to.
Moving from 16-bit to 32 required a bit of abstraction, and Forth has always been a bit stand-offish about abstraction. To convert a 6800 or 6809 Forth to the 68000, for instance, many just kept the 64K memory model. (Can you imagine?) The actual conversion required going back through the source code carefully, looking for instances of "2 +" sequences that marked incrementing to a next address and changing those to "CELLWIDTH +" or some such. Not just that, of course, but you really had to understand the low-level source and you really had to take time doing it.
For people who had done it before, implementing a new Forth for a new 8-bit CPU was quick and painless when you had a full IDE to start with. Almost all the heavy lifting was high-level. But you couldn't do that when you jumped from 16-bit addresses to 32-bit. You could still do a lot of high-level, but you had to slow down, and the market was cut-throat enough to scare you about slowing down when you weren't sure how much you'd have to slow down.
Now is that more than you thought you wanted to know about this?