Tentative responses:

a) I personally find using scripting languages more cumbersome in the medium to long term when I need to maintain, debug code, and optimise code. Every time I see a scripting/dynamic language, I'm turned off from extending the software that embeds it because debugability and performance will inevitably become a problem.

b) I'm not convinced of the alleged "tons of potential issues" that arise from using a compiled language. The extension can be distributed as C code (or whatever compiled language the text editor's community has decided upon). Every platform has a C compiler. I'd argue that C is the most portable language available. Extensions that don't compile will simply fade away, as do extensions in any scripting language, when they don't work. (There is no need for a complex build process or autoconf or whatever other frustrating arcane/convoluted build systems we've somehow been convinced are necessary.)

c) A dll is a shared library. By definition, that is reusable code. There's no necessity that "different languages" be encouraged, merely _a_ compiled language. Even if one extension were to be written in rust/zig and I choose to write an extension in C, is it really so hard for me to read the code I need from that extension and transcribe it for my purposes? I'm not convinced by the "reusable extension code" argument because I have not seen any statistics to justify it and I'm wary of anecdotes, including my own. How much of vim plugins or emacs extensions or vscode extensions are reused code from other extensions? Is it significant enough to raise this (that scripting language code is somehow more reusable) as an argument in defence of scripting languages as extension languages?

d) Patently false I think. (Recall also that emacs didn't successfully mitigate this case for a long time and extensions in elisp could crash the editor.) It's just as easy, if not easier, to mitigate this kind of thing in C. A loaded dll or function can be run easily in a separate process or thread or whatever else one desires. (Didn't plan9 ACME implement communicating processes, an architecture that might be suitable as mitigation of the sort you describe?)

(Also, reinventing the wheel is a bugbear that we should let go of. Attempting to reinvent a wheel is the only way by which one can truly understand how a wheel works. We shouldn't lose this ability or desire. The more we reinvent wheels, the better we get at examining fundamentals efficiently. If we don't reinvent wheels, we'll eventually lose the ability to make wheels.)

f) Claiming "memory leaks and such" is a bit too abstract for me to understand what you mean. I've seen an emacs extension gobble up gigabytes of memory and crash the editor. I suspect I can write such an extension even today. The fault and responsibility would be mine, the extension writer's. I've seen python scripts consume all of a system's memory. There is no magic bullet that solves how much memory a program needs and when the program needs the memory. The programmer has to solve these things.

I do not have any experience in AAA game studios. That said, I haven't heard of scripting languages being used extensively in recent years: A cursory glance at GDC presentations over the past 5 years doesn't reveal much emphasis on scripting languages or on the great successes you allude to. I gather from this that they've mostly been abandoned, excised from engines, or play a relatively insignificant role in the engines used for such games.

I'm not convinced that compiled languages constitute a significant barrier to entry merely because they are compiled and have low level facilities. That would only be possible if programmers somehow didn't have a working understanding of how CPUs and memory work, could only function with a garbage collector, and were unable/unwilling to run compilers like gcc or debuggers like visual studio, but such a person wouldn't meet the definition of "programmer" anyway, I don't think. My assumption is that a text editor, in particular, is being written for programmers.