Largely this problem which is core to Emacs in the sense it literally is "An Elegant Weapon For A More Civilized Time" due to its age. There is no concept of sandboxing anything in Emacs. You do get an alert sometimes when you change Theme's since they have a notion of totally executable code. Maybe a better solution would be to make a subset of elisp that artifacts be coded in which are sandboxed.
No sandboxing is not a bug, it is the feature that makes emacs into elisp platform, and not just another editor that has defined API for extensions.
This problem is specific to elisp evaluation. It is rare that you would want to work in elisp code and not be modifying your currently running emacs.
If you are working on code for any other language, it is probably using an LSP or other form of child processes, right?
Well I wouldn't say any other language. Common Lisp for example you have a currently running lisp instance that you are modifying.
You can pretty easily set up Emacs to work that way for any language with a REPL.
Fair, though with the CL/Python/Whatever you would have to have a session started before visiting the file. I suppose with the newer eglot and friends, it could reach out using LSP as soon as you enter a project directory? At that point, I'd assume similar attacks exist in those contexts, too? Maybe protected by some sandboxing in the LSP side?