Maybe it's just personal preference, since I think it's easier for me to think in python over lisp (which I've known for longer, but I still fumble through)
I do think python would make emacs more accessible to a wider audience.
> I do think python would make emacs more accessible
It would not be Emacs anymore. Emacs is specifically tied to Lisp. Emacs is not a text editor that uses Lisp as the configuration language. Emacs is a Lisp machine that has a text editor built into it.
An "Emacs-like" editor built on Python might be interesting, but it wouldn't be a "better Emacs" or even "like Emacs", it would be a completely different thing.
You may dislike Lisp, you may even hate Lisp, but the fact remains unchanged - there is an emerging class of applications that is significantly more difficult to build around non-homoiconic languages. Emacs is one of them. Stop fetishizing your favorite programming language as the quintessence of Emacs. The best one can do is to build a compiler/transpiler to spit out Lisp code, and people have tried that. Yet somehow, in over forty years nobody has succeeded in dethroning Elisp from ruling Emacs.
GNU Emacs is tied to Elisp. But Emacs is a much wider family of editors written in a multitude of languages.
> Yet somehow, in over forty years nobody has succeeded in dethroning Elisp from ruling Emacs
That might have several reason. Maybe few people are interested to reimplement GNU Emacs in a different language. Like nobody has succeeded in dethroning C from the Linux kernel, using Lisp.
> Emacs is a much wider family of editors written in a multitude of languages.
Sure, there's Guile Emacs, there's MicroEmacs - both not Elisp-based, still built on top of Lisp dialects; there's XEmacs, Remacs - both still use Elisp, there's also mg which afaik completely not lisp-based, but I don't know how much of it still 'emacs-like'. In general though, GNU Emacs is what people usually mean when they speak about Emacs, unless they're explicitly talking about others.
If you say only Lisp can be used to implement Emacs, would you mean a specific Emacs or an editor belonging to the larger family of Emacs-like editors? When I would speak about how to implement "an Emacs", I would include the option to use different programming languages. For example I could imagine that C and Python is a valid combination, even Python alone would be an option. Python can be used interactively, which would be sufficient for an interactive extension language.
You can see that there is a multitude of editors in the Emacs category. The list also mentions the implementation and the extension language.
> GNU Emacs is what people usually mean when they speak about Emacs
That's a bit sad. It's like saying "Linux" and think that its the same as "Debian Linux". Similar there are a lot of different Emacs-like editors. Claiming that there is only a single way to implement Emacs goes against the evidence that there are a lot of Emacs-like editors, which are not implemented in C + Emacs Lisp, including the original first Emacs.
I would think that by far the most important Emacs is GNU Emacs, but I don't think its implementation language choice (C + Lisp) is necessary to implement an extensible Emacs-like editor. Also be aware even though GNU Emacs is a popular Emacs editor, there are some people who are using different Emacs-like editors instead. I typically use a Hemlock variant written in Common Lisp and Zmacs, written in ZetaLisp. Both core designs date back many decades, actually even before GNU Emacs existed.
> I typically use a Hemlock variant written in Common Lisp and Zmacs, written in ZetaLisp.
So, I still can't see how that doesn't prove my point even further. These Emacs variants are based on Lisps, like you just said. I don't see anything "Emacs-like" today that's hugely based on a non-homoiconic language. Please, if you know any editor that allows me to modify the behavior of any given function/procedure/command with the same level of granularity as the advising mechanism of GNU Emacs, I would love to know about it.
Look at the list of Emacs-type editors. Plenty of them were not written in Lisp.
> Please, if you know any editor that allows me to modify the behavior of any given function/procedure/command with the same level of granularity as the advising mechanism of GNU Emacs, I would love to know about it.
Zmacs did that before GNU Emacs existed. It also allowed ALL parts of the editor to be changed, not just the ones written in Emacs Lisp for GNU Emacs. Remember, the core of GNU Emacs - both the core Lisp implementation and some core editor and UI functionality - is written in C.
Btw., on a real Lisp Machine the editor (Zmacs) was not the main user interface. For example on a Symbolics (but also in Interlisp-D), the listener and a file browsers were their own applications. Zmacs in Genera has a Dired mode, but no listener. Also Genera can run multiple Zmacs windows in the same Lisp, running concurrently -> the Lisp supports multiple threads and the applications use that feature.. Something which GNU Emacs can't easily do. It's mostly blocking and single threaded. Something which can't be easily fixed in Emacs Lisp.
Run Lisp code in GNU Emacs in the REPL (m-x ielm) and it blocks the UI. That can't trivially fixed and is a major implementation fail of GNU Emacs.
Other Emacs-like editors can run multiple things, without blocking the user interface.
Maybe it's just personal preference, since I think it's easier for me to think in python over lisp (which I've known for longer, but I still fumble through)
I do think python would make emacs more accessible to a wider audience.