(This article is full of errors; the author doesn't seem to know much about FORTRAN, BASIC, or LISP.)
Paul Graham wrote an article about this in 2001, "What Made Lisp Different": http://www.paulgraham.com/diff.html. He lists nine features: conditionals, first-class functions (though not, at first, closures), recursion, dynamic typing (and what I called the object-graph memory model in http://canonical.org/~kragen/memory-models/), garbage collection, no distinction between functions and expressions, a symbol type, a notation for code using trees of symbols (and thus the ability to add macros), and the whole language always available (no strong distinction between compile-time and runtime, dramatically simplifying macros and other forms of metaprogramming).
As Paul points out, these features got adopted by other languages gradually over time, but in 1960 or 1970 or 1980 or even 1990, if you needed garbage collection and dynamic typing, or to pass around functions as values, or to do metaprogramming, your non-Lisp options were very limited. Prolog or Smalltalk might be a possibility, but usually they weren't. So Lisp was extremely popular. It was really the only reasonable candidate for an embedded scripting language in the 1980s, so that's what Emacs and AutoCAD used.
By contrast, consider the currently-popular crop of languages: Java, C, Python, C++, C#, VB.NET, JS, PHP, SQL, Objective-C, Ruby, assembly, Swift, Matlab, and Groovy, say. Let's omit SQL and assembly from what follows. All of them have conditionals; all of them have first-class functions (though in C, closures are a nonstandard GNU extension); all of them have recursion; all except C have some form of dynamic typing, and half of them are purely dynamically typed (except C, C++, Objective-C, C#, Java, VB.NET, and Swift), and even more of them use the Lisp object-graph memory model; all of them are garbage-collected (except C, C++, and sometimes Objective-C); many of them have a symbol or "atom" type (Python has intern(), Ruby has symbols, Objective-C has SEL, Swift has Selector, and JS just acquired Symbols in ES6); and most of them support Turing-complete metaprogramming in one way or another: templates in C++, "eval" in Python and JS and PHP and Ruby and Matlab, "Eval" in Groovy, and loading dynamically generated bytecode with a fresh ClassLoader in Java.
Metaprogramming merits special attention here; fully a third of Paul's items (symbols, representing source code as a tree of symbols, and the lack of compile-time–run-time distinction) are about metaprogramming, and those are the items that are not widespread today. The main use of metaprogramming is implementing embedded domain-specific languages, which you could reasonably argue is the most important part of the Lisp approach. (Certainly the article claims that it's what sunk Lisp.) But there are ways to implement EDSLs other than compile-time code evaluation to modify your source code while represented as a tree of symbols, and indeed the immense difficulty experienced in solving the hygienic macro problem in Scheme (getting to Macros That Work) suggests that it may not even be the best way. You can get a long way by using reflection instead of macros, and in Python you can override __dunder__ methods, implement iterators, and write metaclasses; in Java, in addition to firing up OW2 Asm and generating new classes, you have @annotations; in Ruby and Objective-C, you have method_missing and -doesNotUnderstand:; in object-oriented languages in general, you have virtual method dispatch (including but not limited to the Interpreter pattern); and in Ruby you have block arguments, and the ES6 => syntax is lightweight enough to be used in the same way. (I don't know several of these languages well enough to comment on their metaprogramming facilities.)
So the real story is that most of Lisp's features went mainstream, and every popular language has them, so they are no longer a reason to choose Lisp stricto sensu. They do differ in how to implement metaprogramming, Lisp's most radical feature, as did Lisp — fexprs are nowhere to be found in Common Lisp (or in McCarthy's 1959 Ur-Lisp), and Scheme hygienic macros are another game again, one which also doesn't provide an S-expression API to the macro-writer.
(The expression–statement dichotomy is an exception here. It's true that Lisp doesn't have it and most modern languages do. I think this is an example of the tradeoff between error detection and succinctness I described in http://www.paulgraham.com/redund.html — the expression–statement dichotomy improves the reporting of parsing errors considerably, and the compensating expansion of your code is almost insignificant.)
FigBug argues in https://news.ycombinator.com/item?id=20375596 that Lisp stricto sensu failed because it had no killer app (other than, I suppose, Emacs and AutoCAD), because most developers don't pick a language, but are rather constrained to use the language demanded by their environment: JS in the browser, C for Unix, Java for Android. But that just poses the question of why Android uses Java instead of a purer Lisp, why the browser uses JS instead of a purer Lisp, and so on. It just reduces the adoption decision to a smaller group of programmers.
There were a couple of other historically contingent things that happened, which don't have anything to do with the merits of the languages as such: around 1988 the AI Winter and the workstation revolution wiped out the Lisp companies; around 1995 the internet went mainstream and for a while all the interesting development was in Perl 5, partly because of its Lispy qualities but also because its attitude toward Unix was the extreme opposite of Lisp's; and the microcomputer world developed its own programming traditions, despite the noble efforts of magazines like BYTE to bridge the gap. Presumably something similar is happening right now in Shenzhen.