I would happily write stored procs using the current language support for a decade without pay, before I'd subject myself to putting javascript in a fucking database engine.
> And how is it "minutiae" to be able to figure out "is my database version actually supported"?
Remembering "8.4", "9.7" and ".4" just doesn't seem like a particularly big deal to me. The number* has only changed 3 times in the last 10 years.
I don't like JS either, but lots of people do. And if you're expanding a DB beyond SQL-only, JS is an obvious first choice before adding further languages from there. (The MySQL feature is called "Multilingual Engine Component" and not "JavaScript Engine Component".)
As for the versioning, it's a nightmare for third party vendors like me, because it will absolutely increase the number of companies who are unintentionally running unsupported non-LTS "innovation" releases because they can't keep all these versioning changes straight. The major-version only changed 3 times in the past decade because 8.0 was "evergreen" for most of that time, which was also not a good strategy, yet the most obvious solution (SemVer) is always ignored by Oracle in favor of more confusing alternatives.