I enjoyed skimming over this again -- I happen to be the guy who wrote the first comment on it.
I'm pleased to say that I've stuck with CL, and I'm glad I did. I've managed to use it at work, and have been using it to build something I can't picture doing (easily?) in any other language. I've managed to pique the interest of a few coworkers, too.
Much of what the article says is indeed true, but I just don't feel they're as problematic as they're made out to be. There are some ugly corners of the language, but they're, in my opinion, vastly outweighed by a fearsome arsenal of tools at your fingertips. I'd contend that it's warts are "warts in the small" -- some weird naming, some inconsistencies in usage. Other languages -- even pretty good ones -- have problems in things as basic as their scoping rules. I believe that by comparison, CL is actually pretty reasonably designed.
Author's point wasn't that Common LISP couldn't do such a thing. It's whether Common LISP's issues and troubles are justified in process vs examples like Racket cited. How hard would it have been to do your project in Racket which seems to be able to do whatever Common LISP can do and with more consistency in language?
Haven't spent enough time with Racket, but my understanding (correct me if I'm wrong) is that you won't squeeze as much performance out of it, and performance is quite important. I'm also quite partial to Lisp's condition system -- I don't believe Schemes can support something that comprehensive (a trade-off for having nice things like call/cc, I think?)