The most important ones are fast build/startup times and informative error messages. They can focus on actually debugging your code instead of waiting for the compiler or looking up obscure error codes in the docs (if they have web access, if they don't they will hallucinate).

Lisps are great for fast iteration but the syntax is a big problem because it's so sensitive to a single misplaced paren. LLMs like clean syntax with as little noise and unnecessary tokens as possible. They work better with dynamic or inferred types, low verbosity, no repetition like `Foo foo = new Foo();`, clearly delimited blocks, you get the idea. Parts of the language should compose well so the chance that a reasonable edit will cause a syntax error is as low as possible.

Popularity was a big deal with early coding models that couldn't go from specific languages to a wider idea of programming. Modern LLMs can generalize a lot better and use Rhombus or Gleam with no major issues, but they still work better in Python or JS with more training examples.

Basically the things that make a language LLM friendly are the same ones that make it human friendly, at least if your human is an average developer instead of a FP fanatics or enterprise architect.