In the Reddit comments of this thread, I have made a comment that turned out to be surprisingly long and off-topic - it didn't answer that particular question related to the linked article, it replied to the article as a whole. Hence I've decided to turn it into a whole separate blogpost.

This article has some points that make no sense to me.

Things in CL, even the nicer ones, can come back to bite you big time. And if you get cocky, expect a lot of pain.

That argument is meaningless. Substitute CL with any other programming language and the meaning stays the same.

As mentioned in my previous post, all the Lisp I wrote was using the Franz AllegroCL compiler

Most CL compilers come with default optimization settings that are safe, and if you abuse those, be ready for the pain.

"I used only a single implementation" clashes with "most implementations can screw you up with invalid proclamations".

You can have the most optimized and safe code available, and then you include a new dependency into your project that perhaps does some fancy optimization and then suddenly your app catches fire like no other.

"A new dependency that does some fancy optimization", to me, means that that particular dependency has unsafe code. This should nonetheless be visible in the stacktrace of any errors that happen, and if it doesn't, then the modularity of your code that calls that dependency needs to be fixed.

and if you get too cocky, you’ll pay the price

Just a stylistic remark, but the author could have used this and the related phrases about five times less, and the text would be a little bit less pretentious.

On the other hand, the arguments about using lists everywhere, dirty Lisp images, lack of a Lisp "community", small number of programmers, and people flocking to other languages, sound quite valid for me.

Using lists that aren't alists or plists is very easy for quickly hacking things together, but the lack of structure comes to bite the programmer later.

Dirty Lisp images are an issue and they have given me countless times where the code I've pushed didn't build in the first place. It forced me to learn to frequently reload the image during development, especially before pushing, and to ensure that the code loads from a clean Lisp image.

Lispers are not only scarce, they are fragmented, just like their libraries. There exist many JSON libraries, each of them being used by other programs; the same thing happens with other libraries (UIOP vs CL-FAD vs PATHNAME-UTILS, to name one).

Lots of other languages have taken features from Lisps to the point where they're "Lisps without the S-expressions". Paul Graham's original points are a sign of that: nowadays, only point 8 is unavailable in Rubies/Perls/Pythons, and point 9 is theoretically available, even though it's hard to make use of it during compile-time, since access a particular program's syntax during compilation time is nowhere as trivial as it is in Lisp.

To quote Ron Garret from his pretty great article:

I noticed that all around me people were writing code using C++ and Java and Python and even (gasp!) Perl, and they were actually getting it to work without tearing their hair out. In fact, in a number of cases I saw people whip things up in Perl in a couple of hours that would have taken me days or weeks to do in Lisp.

The conclusion was inescapable: the problem wasn't Perl or C++ or Java, it was me. I just wasn't a very good programmer any more. Lisp's power had made me complacent, and the world had passed me by. Looking back, I actually don't think I was ever a very good programmer. I just happened to have the good fortune to recognize a good thing when I saw it, and used the resulting leverage to build a successful career. But I credit much of my success to the people who designed Common Lisp.