You are just showing the application areas and the "best" languages for them. If this is the way you approaching languages, then the problem is not with Lisp, but with your application area. Find an application area first, then design an environment to solve the problems of that application area using Lisp. The next step is to create a community of people interested in solving that problem, and finally offer the Lisp environment to that community.
> If this is the way you approaching languages, then the problem is not with Lisp, but with your application area.
No, the problem is with CL (not "Lisp") if:
a) it doesn't provide something compelling enough to make me use it over another language
b) the community hasn't created enough buzz around it to place it firmly in my consciousness next to some problem domain (at least one)
> Find an application area first, then design an environment to solve the problems of that application area using Lisp. The next step is to create a community of people interested in solving that problem, and finally offer the Lisp environment to that community.
Yep, this is what needs to happen for CL to have a chance to go mainstream. The important thing is that the application area needs to be very common, e.g. webapps, and the offered solution needs to be radically better than the alternatives. Think Rails <-> Ruby back in 2005. CL may be the best thing for hardcore AI stuff, but few programmers work on hardcore AI problems.
Your examples are off btw. AutoLisp and Emacs Lisp are embedded languages, not something you'd write a whole standalone app in. It's like saying that if you want to write a spreadsheet, you should use VBA because that's what Excel uses for scripting.
It has worked before with:
CAD application -> Autocad Lisp
Text editor -> Emacs Lisp