I would agree with you, if the notion of Lisp was actually well-understood. But, unfortunately, I observe the contrary very often. That's exactly why I've wrote this rant.
> It's not so much a question of "Why Lisp?" as it is a question of "Which Lisp?," if you ask me.
I can't imagine a similar question about C: "Which C would you use, gcc or clang, C++ or Java?" Can you? And that is because everyone understands what is C. Yet, I think, this understanding won't impede people from discussing something in the lines of "Is Go an acceptable C?" Just because C is so well understood you can clearly reason of it. But if you will say, that you use Lisp in a broad sense, this won't tell anything about your project, because it can be a very functional Clojure entangled with a lot of Java, or very academic and "pure" Scheme, or Common Lisp, or some obscure and very different dialect, like Nu or newLisp, or you've added your own "Lisp" dialect into a project... This doesn't help understanding, and it so happened, that there so many misconceptions about Lisp, that you have a hard time discussing it with people: first you have to educate them.
Speaking of Emacs Lisp. Indeed, it is a Lisp, and it is, actually, very similar to Common Lisp, just a more dated version, lacking some of the current Lisp features. But this case, likewise the case with AutoLisp, isn't a problem, as everyone can clearly draw a line between a general-purpose language and an embedded environment.
But the question "Which Lisp" is entirely meaningful, more so than even the question, more acceptable by your definitions, "Should I program in in Emacs or Common Lisp?" The programmer asking "Which Lisp?" might very well find that Racket is the language he wants or that Clojure is, since both are similar in capabilities to Common Lisp. The question meaningfully indicates confusion. A person wants to write a real program in a language with s-expressions and a macro system, probably, and any of the languages listed satisfies those goals, and the discussion will focus on the ways they differ. This seems fine to me.
The question should you program in Emacs Lisp or Common Lisp is meaningless. If you program for Emacs, you use Emacs Lisp, otherwise — Common Lisp. It would be very hard for you to do it the other way. I, actually, wonder how much knowledge about Lisp do you have, since you pose such question.
Regarding the question "Which Lisp?", it wasn't appropriate in that discussion, as the article was clearly about the use and features of Common Lisp. It was not discussing how an S-expression-based macro-language was a very good choice. To reduce the essence of Lisp to a simple notion of s-expressions + macros is a huge misconception, that I'm fighting here. Lisp is much more than s-expressions + macros. The proper question would be "Which S-expression-based language I want to use?" And posed in such way you should clearly see, that it is not a fit for this discussion. It would be much better, if everyone understood well the full feature-set of Lisp :)
My point was exactly that the allowed usage you propose, where Emacs Lisp is a Lisp and Clojure, for instance, is not, is quite ridiculous. The disallowed usage, "Which Lisp should I use, Clojure or Common Lisp?" is however, not ridiculous. Your rule excludes a meaningful usage and includes a ridiculous one.
I'm not saying that Common Lisp reduces to s-expressions and syntax extension or even that "lispness" does, only that s-expressions and syntax extension are the features to which the denotation "a lisp" most frequently refers.
Incidentally, I program in Common Lisp for a living and am the author of several libraries in several lisp dialects, which, while not enjoying much use, do demonstrate a working knowledge of the language family. But thanks for imputing my qualifications.
I don't think, that the question "Which Lisp should I use: Clojure or Common Lisp?" is quite correct. As they are really so different in very basic concepts: mutable vs immutable, OO vs non-OO, bootstrapped vs JVM-based, and the list can go on and on. This question is of the same sort of "Should I use Lisp (I mean Common Lisp) or Python?" And it can be reduced t "Which dynamic language should I use?" Or "Should I use Lisp or Java?" - "Which memory-managed system programming language should I use?" Likewise "Should I use Lisp or Clojure?" can be reduced to "Which s-expression based language should I use?"
For example, just a day ago in the previous Lisp discussion on HN (http://news.ycombinator.com/item?id=5031505):
> It's not so much a question of "Why Lisp?" as it is a question of "Which Lisp?," if you ask me.
I can't imagine a similar question about C: "Which C would you use, gcc or clang, C++ or Java?" Can you? And that is because everyone understands what is C. Yet, I think, this understanding won't impede people from discussing something in the lines of "Is Go an acceptable C?" Just because C is so well understood you can clearly reason of it. But if you will say, that you use Lisp in a broad sense, this won't tell anything about your project, because it can be a very functional Clojure entangled with a lot of Java, or very academic and "pure" Scheme, or Common Lisp, or some obscure and very different dialect, like Nu or newLisp, or you've added your own "Lisp" dialect into a project... This doesn't help understanding, and it so happened, that there so many misconceptions about Lisp, that you have a hard time discussing it with people: first you have to educate them.
Speaking of Emacs Lisp. Indeed, it is a Lisp, and it is, actually, very similar to Common Lisp, just a more dated version, lacking some of the current Lisp features. But this case, likewise the case with AutoLisp, isn't a problem, as everyone can clearly draw a line between a general-purpose language and an embedded environment.