The thing with Common Lisp is that there's a great manual to actually refer to. Of course cl-lib isn't a complete replacement for it, in the sense that it's incomplete. So I do agree that it's not a perfect situation.

I came at Emacs from the other direction - I learned Common Lisp first, and then elisp. From that perspective elisp in some ways feels "impoverished", in the same way that for someone looking at it in the opposite direction Common Lisp might appear baroque.

cl-lib fills many of those gaps with the useful delta that has accumulated over time. I think the gaps are real, because there exist various elisp modules to provide utilities that are similar to those that cl-lib provides, for example seq.el and dash.el.

There is nothing wrong with these other modules. But cl-lib has one advantage: it can actually draw from an ANSI standard that won't change. That gives the idioms that it implements, even if they aren't precise, complete implementations of what Common Lisp specifies, a certain stability and predictability. It's not going to go away, and I don't have to think about these things after I've learned them once.

For me this is a large part of the appeal of Common Lisp. The core is very stable and well specified. It has warts. It has many warts. But it's fundamentally quite sound and relatively coherent. And on top of it it's possible to implement just about anything. In some sense elisp is less stable - list manipulation libraries come and go, implementing and reimplementing the same thing in the currently fashionable style. This is because elisp is a very different thing from Common Lisp. Its core is smaller and doesn't need to be as general purpose.

I think people should be free to choose whichever approach they prefer. If you are at all a seasoned Lisp hacker you will not have problems following along. This isn't to say that everyone who contributes must be a master guru uber ninja. I'm saying there's room for both, and removing usages of cl-lib for the sake of removing usages of cl-lib isn't a very productive endeavor. And I think if you need to learn how some code that uses cl-lib or seq.el or dash.el works, you will find the overhead of learning these utilities to be smaller than the overhead of learning how the main module works. I just don't see it as an issue.