It's not just Lisp, it's the lispm. This was true of Interlip-D as well (the PARC lisp environment that ran on the Dandelion (AKA Star) as well as other D machines. It had two factors:

1 - Lisp is a dynamic language -- even compiled code can be modified and supersceded. This makes rapid prototyping really easy; it makes exploratory programming really easy, and it makes it easy to incrementally provide core improvements.

2 - As the entire system is in Lisp ("it's Lisp all the way down") there are no barriers (technical nor conceptual) between user code and system code. When I was developing Cyc I make the frame datastructures (Units and Slots in the parlance) first class objects that behaved exactly as if they were part of the base system distribution. They looked like a fundamendal datastructure just like conses, arrays, integers etc, which means people could rite code using them in ways I hadn't anticipated. Coupled with the introspective nature of Lisp you could easily write patches or new functionality that took advantage of what was on the system. And the debugger was always running, so instead of a core dump you could poke around and see what happened with all the dynamic data intact. (In the D-Machine case, on the project I worked on at PARC we actually added some instructions (wrote microcode) to the machine for this purpose).

Now, let's compare this (good and bad) with the state of the art today:

We definitely have dynamic languages heavily inflected by this work: C++ classes can be indistinguishable from built-in ones, and the entire STL can be written in C++. Clojure, js, etc are mainstream dynamic languages.

But what we still have gain mismatches at interfaces: calling into the kernel is expensive; you have a cost in performance and functionality when interfacing between languages (e.g. a lot of boxing/unboxing when you interface C++ to Python, for example) and the build and development tools are typically disjoint from the program under development, which means the code and tool can't introspect about their relationship with each other. On the other hand, a Pascal or C program on an MIT-style Lispm (Symbolics/LMI/TI) had the same calling conventions and datatypes as a Lisp program and could intercall freely and be debugged clearly.

And people are less interested in that these days: the dominant mode of programming is to assemble large numbers of black boxes and hope that they work. That gives me the heebie-jeebies, but perhaps that's just snobbery on my part: tons of useful systems are being built that way, and by a much larger set of people than used to be considered programmers.

There were downsides of course, many of which are the reason these kinds of architectures no longer exist. The biggest one is the two-edged sword of the simplicity and complexity of Lisp: it's a very simple language with many sharp tools in the toolbox; a new user could very rapidly come up to speed, but most commonly a new user ended up developing a thick rope that they then proceeded to hang themselves with. It's a systems programming language and its very simplicity makes it too complex for most for application development. The same issue affects C++ today: it's an immensely powerful and expressive systems programming language but also a lot to get your hands around. Compare that to Go which explicitly tries to head in the opposite direction.

Another "downside" is exploratory programming: I still use that approach but in terms of full disclosure: a good friend of mine denigrates it as "programming by successive approximation". I can see his point.

And of course the lack of barriers would make applications quite vulnerable in today's security environment.

It's still by far the most productive environment I've ever used, but I'm not sure it has a place in today's world.