There is a kind of negative feedback loop going on here. When universities stopped pushing LISP as an important language to know, that generated fewer people with skills to maintain LISP code, which reduced incentive to program in LISP, which reduced incentive for people to train others to program in it, and so forth.
While it sounds like they're two very different technologies, the closest analogue I can think of is COBOL. I've actually seen COBOL job postings given I work in a town with some finance companies, and while I'm confident I could handle a role working with it, I just don't want to build my skill-set in an increasingly niche area.
COBOL is older, but it is not a general programming language. LISP is a mature, very powerful general programming language. Its code is extremely portable across most operating systems and platforms. Despite all the parentheses, the syntax is quite trivially easy to learn, and it makes the processing of linked lists extremely easy. It handles memory space and garbage collection very well. It comes native as an interpreted language, but one can generate very efficient standalone runtime applications with it. Hence, it is easier to debug than most programming languages that require special environments and tools for that purpose.
I could see others being the same with LISP. Why take a role working with something that's not really used anymore, when you could learn something like Ruby-on-Rails and be in high demand.
I agree. If you aren't writing programs that process language or knowledge structure, then it makes a lot more sense to go with languages for which there is a broad community of support. That used to be the case with LISP, but it is now an obscure language that most young programmers never come into contact with.
Back in the 90s and early 2000s, we had a lot of trouble with our all-LISP natural language program. Boeing wanted to use it in a wide range of applications, but procurement lost the ability to order and pay for licenses. We had to find high level management backing to help cut all the red tape that was blocking our ability to maintain it. At one point, several managers wanted us to convert the code to a "standard" programming language such as C, even though C and C+ at the time was less portable and less easy to debug. They allocated a hefty amount of money to purchase a one-off license for a lisp-to-C converter, not to mention our labor in trying to make the thing work as a production level process. Hence, we had to maintain both the LISP code and the generated C code, which always ended up with glitches in it. Eventually, those managers were rewarded for their successful efforts at converting us to orthodoxy and promoted to other endeavors. At that point, we dropped the C conversion and went back to generating runtime applications with just LISP at much reduced cost for all platforms. We never looked back, and the program still runs fine on most platforms. Integration with large (usually Arbortext) authoring systems was trivial--just one line of code in the customization section and a small, easily configurable wrapper file for handshakes with the host system.