This tracks as the reasoning behind a lack of other browser engines, nobody can get comparable performance without a JIT, which would be compiling net new machine code that wasn't shipped with the binary.
The best way to handle this I would imagine within the current bounds of Apple's restrictions would be WASM.
That was the day I realized that for a lot of people, rules aren't actually rules. They're tools that they can use to stop something they don't like, no matter what the rule is really about.
I think this is a disgusting attitude, but it's unfortunately the way a lot of people operate.
So it might be that Apple has this "no external code" rule to stop things they don't like, and the category of "things Apple doesn't like" doesn't actually include every app that runs external code. It includes a lot of them, but for whatever reason Apple chose not to codify the details. Crummy if true, but I wouldn't be surprised. Every regulator I've ever dealt with leaves themselves an "I know it when I see it" escape hatch that lets them ban whatever they want.
Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.
There are not "exceptions"; there is one exception, and that's educational apps. But it's unclear why Pythonista is educational while the apps mentioned in the article are not. In fact, Pythonista is even listed in the "Productivity" section in the App Store.