Perhaps it's because of typing. Personally I find that structural insights on code from static analysis to be just as important if not more than local readability. I also generally find that it's the complexity of program strategy that impairs local readability more than syntax or style.

Common Lisp has type declarations and I think on a big code base, I would want to declare most if not all of my function types.

And the types are not just for information: the compilers can and do optimise heavily if you ask for it with `(optimise 3)`! You can get nearly as fast as C.

Without a library like Coalton, the type system built into Lisp is pretty limited. (It feels pretty similar to C's.) So you can't[1] declare types like "list of foo" or "function that takes any type and returns the same type".

[1] There is something called a SATISFIES type which lets you turn any globally defined predicate function into a type, but I don't find that it's used widely in practice, because the compiler can't reason about it.

Not sure if separating the language from its available libraries is really helpful...

It is, because libraries like Coalton don't give you an expressive type system "for free", you also have to agree to write your code in a certain way. As such, it's completely reasonable for Lispers to opt out of using such opinionated libraries, and instead using only what's provided by the standard.

If you do use a library like Coalton, then you get a type system pretty close to Haskell's.

Hey, do you use Coalton, and how mainstream would you say it is?

I'm fairly sure that their company created Coalton:

https://coalton-lang.github.io/20211010-introducing-coalton/

It's pretty new and not yet considered mainstream. But it's under active development and is used for real commercial projects.

This may help: https://github.com/coalton-lang/coalton