Firstly, CoffeeScript
is built in JavaScript. Does that make it a 'real' Lisp?
Secondly, Lisp macros are every bit as big a security risk as using eval... That is what the E in REPL stands for, after all. In both cases, if you are taking input from source code, and not from outside sources, there is no security risk.
Thirdly, yes, my example is messy. But it is still doable, and I just have a hard time believing that this kind of programming is a major percentage of the code of a Lisp program. To be clear on that comment, I can easily believe that you end up invoking macros a lot, but I don't believe that a large percentage of the code written for a project is actually macros. What percentage of code in a typical project is macros? And how many of those macros can be easily reproduced by using specialised syntax of a language such as ruby (optional parantheses, blocks, re-opening classes, method_missing, etc)?
This is an important point, because if you only have a few hundred lines of this stuff in a typical Lisp program, and it can be reproduced by using a parser in another (dynamic) language, then the advantage just isn't that big. For argument's sake, imagine having a module available in Javascript that provides the Jison parser along with the Javascript grammar, which just re-emits the original Javascript source. In addition, it has a nice API to allow you to modify the grammar (adding / modifying rules). So far so easy, this stuff already exists in CoffeeScript, go copy it from there. Now, having loaded such a module, is Lisp really in a much better position than this modified Javascript?