That is the approach I had to take with LaTeX generation, but it’s far from ideal. There will be users who toggle it accidentally, or toggle it and forget about it, and they’ll be at risk from that point onwards. And if any popular shared decks/templates/add-ons start depending on the API, that will encourage more users to put themselves at risk.
I’m sorry, I don’t think it would be responsible to introduce this new functionality without ensuring it’s secure from the start.
And there’s more than just an iframe to do - Anki and AnkiMobile currently have no way of distributing/installing JS outside of card templates and Python add-ons. AnkiDroid has an initial implementation based on npm, but that’s only a partial solution, which doesn’t cover things like a browsable list of available add-ons, reviews, etc.
That may be a good idea for other reasons. But the issue is that Anki’s internal code, and any add-ons, would need to hold the authentication key. If that code is running in the same context as shared deck JS, we risk the shared deck JS being able to extract the authentication key and make its own requests.
I’d rather see card templates using less JS, not more. A lot of things being done in card templates currently isn’t necessarily specific to a particular card type (think answer timer, pretty tag formatting, etc). By moving these things out of the card templates and into separate add-ons that can be upgraded separately, it should make the shared decks more robust against upgrades, and hopefully make the templates less daunting to users as well.