All this poetic non-sense about flexibility and writing prototype programs is irrelevant. Lisp has real technical flaws that prevent its use:

1.GC that prevents it from using real-time and performance-oriented code.

2.Pervasive use of inefficient lists and dynamic typing, which puts steep memory requirements on top of performance costs.

3. Arcane write-only syntax which becomes context sensitive with Domain-Specific Languages which Lisp programs devolve to, creating unreadable and overly condensed spaghetti code(especially macros), making existing code inaccessible for developers.

4. Huge runtime which is embedded in every executable, that makes it less competitive with scripting languages. Lisp requires eval() and runtime interpretation which other languages optimize out and replace with fixed code paths. (some external programs called "tree shakers" remove the lisp's runtime cruft, but they're exception rather than rule)

5. Lisp has very loose safety. Any piece of data can be potentially executed at runtime and lisp programs have to be excluded from WriteXORexecute/NX protection, since lisp code/data are intermingled. Executable stack and heap expand areas for exploits and create a general lack of stability - any bug can corrupt running code, Lisp is so far removed from any concept of safety it even allows the programs to be modified at runtime(this is a fundamental feature shared with polymorphic viruses).