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".