There isn't anything profoundly wrong with Elisp. Emacs needs a programming language, Elisp is a programming language and that is the end of the story, more or less.

You can level complaints against Elisp. You can level complaints against anything. They aren't a big deal - Elisp supports variables, loops and if statements and that is enough to implement a text editor to a first approximation.

If the slate was wiped clean, the Emacs community would probably prefer that Emacs was written with Common Lisp. Then Emacs wouldn't need its own lisp reference manual.

I can't speak for the Emacs community, but like to caution that Common Lisp is a large language and IMHO would be too much a burden to learn for someone just to customize or extend the editor. I'd rather think it's the Common Lisp community who would prefer Emacs to be written using CL ;-)

Emacs Lisp gets there anyway, somehow. Just decades later.

Examples:

Lexical binding. SCHEME in 1975, Common Lisp in 1984. GNU Emacs in 2012.

Native compiled code. LISP 1 got that in 1960. There are now native compiled code builds of GNU Emacs since a few years.

Cooperative threading. Common Lisp had that in the 80s. Other Lisp dialects probably earlier. Now concurrent native threads would be a thing, so that Emacs Lisp too can take advantage of preemptive single and multi-core threading.

But (setq variable var) looks the same in CL and ELisp, so it takes the same amount of learning to customize, right? It is not more to learn just because there exist more possibilities in the language.