VS Code does exactly that, warns before loading this non-interactive code. It warns you loudly, with an ugly modal dialog, on opening a new to it folder and suggests Restricted Mode. A lot of the arguments here relate to:
1) This loud warning is easy to ignore, despite how loud it is
2) This loud warning is easy to disable, which many desire to do because it is very loud
3) This loud warning is easy to build bad habits (instead of marking safe parent folders, continually clicking Allow and training yourself to only click Allow)
4) Restricted Mode sounds "too restricted" to be useful (though it isn't too restrictive and is very useful)
5) Restricted Mode is also loud to remind you that you are in it, so many users think it is too loud and never want to be in it (despite it being very useful)
Maybe I'm confused at what you mean, but I don't think there's a huge difference. Loading code is a dangerous action. VS Code is doing exactly what the video is talking about: it gives you a big popup window before doing a dangerous action (that could violate your privacy, that could be malware, that could do things you don't expect).
We want to load code in Turing complete languages. We want complex build tools and test harnesses to load "just so", and those too are generally Turing complete and configured and written in Turing complete languages. Parsing code in a Turing complete language takes another Turing complete language, generally. (Most languages are self-hosted so parsing the code is an action in that same language.)
One of the most dangerous actions we know of is an ancient and inescapable "bug" in all Turing complete work: the Halting Problem. We cannot mathematically prove any program will complete nor when it will complete, without running it and waiting for it to complete, if it completes. Infinite loops are both the power granted to us by our tools and the potential downfall of them all, our responsibility to deal with them is in our hands and math can't help us enough.
Loading code is a dangerous action. VS Code is doing the right thing in how it is handling it. It's not the best user experience and clearly not enough users understand the dangers inherent in "do you really want to run all your extensions in this folder?" in precisely the same way that people better understand "Do you want this application to have access to your precise location?" is a threat (that apps do take advantage; in both cases).
Some instructions are benign, eg to add two numbers or even divide by zero
Other instructions call APIs of the OS
It is at these times that the user should be prompted interactively whether they want the action to be done, with full details of what the scope is, and keep asking every time until the user checks a box that says “continue allowing this action on this scope to THIS program”.
I think I see what you are asking: why isn't it more granular?
In VS Code the granular options exist, too. Restricted Mode is just a pseudo-profile with (almost) no Extensions loaded and a couple other settings disabled. You can use the VS Code profiles and workspace controls to set many other granular in-between states.
I think where the fundamental disagreement I have with your perspective lies, and it is sort of the decades-long "lesson of Windows and Office" (which I'll circle back to) and also one of the deepest, oldest theoretical concerns of Computer Science, is that there is unfortunately no such thing as "benign code". The Halting Problem and its corollary the "Zero-Day Sandbox Exploit in the Universal Turing Machine" suggest that mathematically we have no real tools to determine what is actually benign versus what looks benign.
If you don't like the math theory side of that argument, then we can absolutely discuss the practical, too. We can start with the example you have given that even divide by zero can be benign. That's a pretty good example. We've designed computers so they don't halt and catch fire on a divide by zero, sure, but to do that we have things like stateful error registers and even processor interrupts to jump immediately to different code when a divide by zero happens. Other code could be relying on those error registers as well and may get to its own unexpected state. Interrupts and jumps can be taken advantage of to run code the original program never expected to run.
Little processor-level details like that add up and you get giant messes like SPECTRE/MELTDOWN.
That's also just one low level place to inject malware, you can do it in any programming language anywhere in the stack. This is where VS Code is especially in such an unenviable position because it wants to be a development environment for all possible programming languages so has just about no idea what the full breadth of the stack of programming languages you've configured to want to run in the Extensions that you've installed and the CLI tasks it can automate. VS Code isn't your Operating System (it is not yet trying to be that much like Emacs), it doesn't sandbox your Extensions, it doesn't limit what APIs the CLI build tools you have installed can run.
There are practical exploits of this directly in the article here. More can be found with easy searching. Granularity only helps so much. A big general, loud warning isn't the best experience, but its the closest to the safest option available to VS Code (not just because it isn't your OS, and also OSes are omniscient).
The safest option for VS Code really is "Don't autostart anything, it might be dangerous". Just as Windows has had to stop autorunning JScript and VBScript (once considered "benign"). Just as Windows has had to stop autorunning AUTOEXEC.INI instructions when a CD or USB disk is inserted (once considered "benign"). Just as Office has had to stop running VBA macros on startup (once considered benign). I wish VS Code took a couple more steps towards the Excel experience ("Protected Mode" sounds kinder than "Restricted Mode", it's a subtle difference, but subtle differences matter; fewer flow-interrupting modals and more "quietly default to Protected Mode"), but the general principle here isn't in question in my mind.
But going back to this is also deeply and disturbingly tied back to some of the oldest theories and questions of Computer Science, it also seems useful to remind everyone that if you want to feel truly paranoid, the only safe way to use a computer is to never use a computer. We don't know how to differentiate benign code from dangerous code, we likely never will. Not your OS, not your code editor, not even your abstract Universal Turing Machine you are running with pencil and paper. Unless we find some sort of left-field solution to the Halting Problem, we're kind of stuck with "Computers are inherently dangerous, proceed with caution".
1) This loud warning is easy to ignore, despite how loud it is
2) This loud warning is easy to disable, which many desire to do because it is very loud
3) This loud warning is easy to build bad habits (instead of marking safe parent folders, continually clicking Allow and training yourself to only click Allow)
4) Restricted Mode sounds "too restricted" to be useful (though it isn't too restrictive and is very useful)
5) Restricted Mode is also loud to remind you that you are in it, so many users think it is too loud and never want to be in it (despite it being very useful)