I don't really understand the author's point. He asks what the point of supporting a compiler is when the result is not any faster when his own benchmarks show that the SBCL compiler is significantly faster.

Also, any combination of lisp and CamelCase should be avoided on principle.

The key to the authors point is this sentence - "One of the greatest mysteries in the history of computer language comparisons is to me the question why most people are more interested in the relative speed of a language implementation, rather than in features like expressiveness, flexibility and orthogonality.". The author appears to believe having a lisp which ~5x-10x slower is a worthwhile tradeoff to make if the underlying lisp is simpler, more flexible and more expressive. PS: I am not suggesting that picolisp is simpler, more flexible or more expressibe.

Having skimmed the PicoLisp interpreter a long time ago, I remember it being like Emacs Lisp in that common performance-critical functions like mapcar were implemented in C. It seems like a very pragmatic way to get the performance you need without getting into byte codes or machine language. And since you are still interpreting the s-exprs directly, debugging and introspection remain easy.