You sure about that? From the linked paper ( unfortunately behind all kinds of paywalls...)

"The major characteristics of our process are

- 1) coordinated development of the operational scripts and the flight software,

- 2) an incremental buildup of the operational requirements,

- 3) recurring integrated testing. Our iterative script implementation process addresses how to gather requirements from a geographically dispersed team, and then how to design, build, and test the script software to accommodate the changes that are inevitable as flight hardware is built and tested.

The concurrent development of the operational scripts and the flight software enables early and frequent "test-as-you-will-fly" verification, thus reducing the risk of on-orbit software problems...."

“ 3.1. Event-driven Operations

The JWST science operations will be driven by ASCII (instead of binary command blocks) on-board scripts, written in a customized version of JavaScript. The script interpreter is run by the flight software, which is written in C++. The flight software operates the spacecraft and the science instruments.”

and in section 3.5, sounds like javascript just has an API to lower level system functions:

“ ScriptEase JavaScript allows for a modular design flow, where on-board scripts call lower-level scripts that are defined as functions.”

[0] https://www.stsci.edu/~idash/pub/dashevsky0607rcsgso.pdf

I am mostly curious as to how they came to JS as the embedded scripting language of choice, as opposed to Lua or Scheme or anything else.

It would have had to be an interpreter that was available off the shelf when this was being designed (so late 90s or early 2000s?) that ran on vxWorks on an old PowerPC processor. That could have limited the available choices.

"They" is likely the contractor. It may be simply a choice that allowed them to be lowest bidder