Lisp has a lot in common with Forth in that people often reduce it to a trick and miss the lesson it has to teach; people implement their six words from the bare metal and use those six words to implement Forth but never seem to make the leap, realize they can take it one step further and implement the language they need for the task at hand just as easily as they implemented Forth with those six or however many words they decided to start with. Sure it may not be the most efficient solution but in a time when most people walk around with half a dozen cores in their pocket, counting clock cycles is generally not a concern and it can probably be more efficient than the batteries included solution that comes with eight D cells when it only requires a single coin cell. But there is something about the weight of those eight D cells, they are substantial and we can feel it.
I believe Lisp is relatively more understood than Forth these days, in that most of the "big ideas" that have been built in it have also been borrowed and turned into language features elsewhere. We have a lot of languages with garbage collection, dynamic types, emphasis on a single container type, some kind of macro system, closures, self-hosting, etc. These things aren't presented with so much syntactical clarity outside of Lisp, but they also benefit from additional engineering that makes them "easy to hold and use".
Lisp appeals to a hierarchical approach, in essence. It constrains some of the principal stuff that "keeps the machine in mind" by automating it away, so that all that's left is your abstraction and how it's coupled to the rest of the stack. It's great for academic purpose since it can add a lot of features that isolate well. Everyone likes grabbing hierarchy as a way to scale their code to their problems, even though its proliferation is tied to current software crises. Hierarchical scaling provides an immediate benefit(automation everywhere) and a consequent downside(automation everywhere, defined and enforced by the voting preferences of the market).
Forth, on the other hand, is a heavily complected thing that doesn't convert into a bag of discrete "runtime features" - in the elementary bootstrapped Forth, every word collaborates with the others to build the system. The features it does have are implementation details elevated into something the user may exploit, so they aren't engineered to be "first class", polished, easy to debug. It remains concerned about the machine, and its ability to support hierarchy is less smoothly paved since you can modify the runtime at such a deep level. That makes it look flawed or irrelevant(from a Lisp-ish perspective).
But that doesn't mean it can't scale, exactly. It means that the typical enabled abstraction is to build additional machines that handle larger chunks of your problem, but the overall program structure remains flat and "aware" of each machine you're building, where its memory is located, the runtime performance envelope, and so on. It doesn't provide the bulldozers that let you relocate everything in memory, build a deep callstack, call into third-party modules, and so on. You can build those, but you have to decide that that's actually necessary instead of grabbing it in anger because the runtime already does it. This makes it a good language for "purposeful machines", where everything is really tightly specified. It has appealing aspects for real-time code, artistic integrity, verification and long-term operation. Those are things that the market largely doesn't care about, but there is a hint of the complected nature of Forth in every system that aims for those things.
Lisp has a lot in common with Forth in that people often reduce it to a trick and miss the lesson it has to teach; people implement their six words from the bare metal and use those six words to implement Forth but never seem to make the leap, realize they can take it one step further and implement the language they need for the task at hand just as easily as they implemented Forth with those six or however many words they decided to start with. Sure it may not be the most efficient solution but in a time when most people walk around with half a dozen cores in their pocket, counting clock cycles is generally not a concern and it can probably be more efficient than the batteries included solution that comes with eight D cells when it only requires a single coin cell. But there is something about the weight of those eight D cells, they are substantial and we can feel it.