If you don't like Lisp for editor programmoing, then an editor which is literally built upon a million lines of Lisp code seems to be a very bad choice. Even providing another extension language won't make the Lisp go away.
The implementation language does not matter to me - I'm not working on the code base, and have no interest in doing so. I don't care that there is lisp there, as long as I don't have to write it.
But this is the point that you're completely missing. Perhaps you have not spent a lot of time with Emacs?
The implementation language does matter a lot in this case, because the part of Emacs that is written in Emacs Lisp (~90% of Emacs) can and should be leveraged (modified, extended or used to build upon) at runtime by users. This is what gives Emacs it's tremendous flexibility and power.
Using anything other than a Lisp with semantics close to Emacs Lisp for user code that leverages what Emacs offers built-in, will be an exercise in frustration since a lot of the power I described will be so cumbersome to access and make use of. It's been tried before, multiple times by people not very familiar with Emacs Lisp, and it has never worked out.
Experienced Emacs Lisp developers immediately understand the futility and pointlessness of such endeavors which is why you never see them attempt them.
