If you're saying the article is uninformed, I think that's unfair. It's clear that the author actually went through the book.
In any case, I'm not sure how far we'll get by substituting his implicit definition of "practical" - allows you to start getting stuff done quickly - with another: "teaches you to build abstractions to manage complexity." What I mean is, a debate over the meaning of the word "practical" doesn't seem like much fun.
I think it's clear that the author thinks SICP, Lisp, and other languages considered "impractical" are in fact valuable to those who want to advance as programmers.
What's most interesting to me, however, is that he's encouraging people to really dig into the magic of programming. And here I think we have a problem.
Since November I've been learning Common Lisp and as of a couple days ago I've been learning Clojure. It's awesome! It's magical. But it's such a pain in the ass to get everything set up! It took me a few hours to finally get Clojure working with swank in emacs without having to use Leiningen. I still don't know how to build a common lisp executable and have no idea where to work.
I feel like those wish want to just learn a language in itself are pretty well served. However, there's a huge gap between the readily-available information we have on a language itself and the information we have on how to actually use that language to build real things.
I've actually started trying to address this at http://nonbeginners.com (So far I've only made progress on the Ruby section. Github: https://github.com/flyingmachine/nonbeginners) , though really I don't know if this is the best approach. My thinking is that, by having an outline of all of the larger environmental concerns involved in using a language, it will make it easier to both find the relevant information and produce it as members of a language community become consciously aware of the kind of information that needs to be made available.
As for the CL executable: this[1] answer on SO contains pointers to the executable making mechanisms for the most common open source CL implementations.
I agree completely that one of the bigger problems with Common Lisp might be that there is not much information readily available how to structure bigger projects. In general I find the projects of Edi Weitz a good read [2].
