That basic assumption is a giant knife-switch that pervasively affects everything in the language and environment. Consider, for example, the generic functions CHANGE-CLASS and UPDATE-INSTANCE-FOR-CHANGED-CLASS. Those functions are in the Common Lisp language standard. That makes no sense unless the standard assumes that a Common Lisp system can modify a program while it runs.
Only a minority of programmers want such systems, but to be fair, only a minority of programmers have worked with them enough to understand them.
Not everyone prefers that style of programming, but most programmers will probably never have the opportunity to find out whether they prefer it. I did have the opportunity, and I learned that I did prefer it. I still prefer it thirty years later.
Get back to me with a Clojure or JS environment that does what I miss from a great Lisp or Smalltalk environment. Let me trigger an error and walk the call stack to inspect parameters and intermediate results. Give me a keystroke to get a list of every other piece of code that calls the function with the error--don't make me wait more than about a second for the list. Let me interactively edit the values on the stack in the suspended computation or, better yet, change their types (and have them properly reinitialized), then resume the computation. Let me redefine a function that's on the call stack and then restart the call using the new definition. Let me serialize the entire dynamic state of the program to disk, copy it to a colleague's machine, and start it up to show my colleague the same error in the same dynamic environment. Let me do all of that interactively without needing to leave the original break loop triggered by the original error. Oh, and package the tools as a single modest-sized executable that I can run with a simple command line or a double-click, that launches in a couple seconds or less.
I don't know of such a Clojure or JS environment. If you do, I would be grateful to learn of it.
Besides the previously-mentioned features, I could build a windowing UI by dragging pieces together. I could build the resulting native-code app for delivery by choosing "Save" from a menu. I could write WDEFs (the code resources that defined window shape and behavior) and other low-level stuff interactively in Lisp. I could patch arbitrary calls with assembly code written and debugged interactively in the Lisp environment (one of the SK8 authors was previously an assembly-language video-game programmer; he was ecstatic about this feature of CCL).
Comparing my current daily-driver development machine to the one on which I was using Coral Common Lisp in 1988, the new machine has twice the word size, 400 times the clock speed, 16,000 times as much RAM, and 400,000 times as much disk space.
Meanwhile, the development tools are in many ways worse, rather than better.
There's a general belief in the tech community that better tech wins. When something works better, hackers will start using it, and if there are incidental barriers, they get solved. None of the explanations I've seen have been satisfactory; I reject the both the idea that Lisp isn't really that big an advantage and that the average hacker isn't smart enough to see it.
I don't think the proposition that better tech wins passes the laugh test. You could argue that I'm a cynical old curmudgeon, though. I've been writing software for a living for thirty years now.
It's not about hackers being smart enough to see Lisp's advantages. It's about them (1) being the sort of programmer who prefers programming-as-teaching over programming-as-carpentry, and (2) getting enough exposure to live-programming environments to see what the deal is. The important advantages are not immediately obvious. They're whole system synergies, and it takes time and experience to grasp the nature of stuff like that, regardless of how smart you are.
Plus, maybe there are just more carpenters than teachers.