(1) no native async
(2) small library ecosystem
(3) CL community NIH syndrome:
> I think the straw that broke the camel’s back was when a few people started making copycat projects that added no real value (other than benchmarking fast) but stole mindshare from all the work I had put in.
These are good points. (1) is a real, true problem with CL (as opposed to things that people commonly think of that aren't actually that bad e.g. syntax), and it's probably not going to be solved in a satisfactory way anytime soon - the design of the language is pretty nice, but seems to exclude first-class continuations (according to [1]), async, and coroutines. (yes, you can emulate these things using macros, but that often involves tree-walking, and results in non-orthogonal features that don't play great with the rest of the language - first-class is always better)
Common Lisp was designed for, and is very good at, representing algorithms under a very specific model of how the world works - that is, single-node and single-memory-space. Its design assumptions don't hold up very well in a multi-node, concurrent world. Yes, there's bordeaux-threads and lparallel, but they feel like hacks, and the presence of GC means that they won't be able to attain the performance of Rust or Erlang (which seems like Lisp for a distributed world - its model of the world seems to be fundamentally distributed, not a bunch of patches on top).
(2) is somewhat unavoidable when you have a small community, but (3) is not (and is highly undesirable). Ideally, the CL community would document all of their published code really well (from the library-author side), and then put some effort into learning how to use (and improve) someone else's code (from the library-user side) instead of rewriting their own 50%-complete version of an existing library, but that would require a significant shift in the attitude of the average CL user, and I'm not sure how to try to affect that.
[1] https://stackoverflow.com/questions/16651843/why-doesnt-a-pr...