I think for many reasons the security model for code execution in HTML and SVG ought to be completely identical. They ought to just be slightly different DOM specifications.
In other words, if I can set an SVG file as the image of an img tag or as the URL in a background-image style property, then I ought to be able to use an HTML file, too— and JS should run in both or neither, with the same sandbox properties. Probably neither.
Likewise, if I can set an HTML file as the contents of an iframe, then I ought to be able to use an SVG file that way, too— and JS should run in both or neither, with the same sandbox properties. Probably both.
Is parsing and rendering SVG well-pipelined at this point? Offhand it might be cache-friendly. I have not tried a simple elapsed-time-in-loop test, but to me geometric screen-painting happens instantly enough.
I can imagine a separate branch in computer evolution, if PCs had not happened, where graphical terminals would have evolved to render something SVG-like, support a mouse, and send back simple mousedown/mouseup/x/y data.
In other words, if I can set an SVG file as the image of an img tag or as the URL in a background-image style property, then I ought to be able to use an HTML file, too— and JS should run in both or neither, with the same sandbox properties. Probably neither.
Likewise, if I can set an HTML file as the contents of an iframe, then I ought to be able to use an SVG file that way, too— and JS should run in both or neither, with the same sandbox properties. Probably both.