It's more nuanced than that. A user might not even have a .bashrc, but you still don't want to allow any random app to create one.
In general, it feels like the security model for the FS has to distinguish things that can be executed, and things that cannot. Which it already does on Unix with +x, but then you've got all the scripting languages that cheerfully ignore that, and all the apps that use executable configs etc. If you can fix all those such that +x is required for any source of executable code on the system, then you can just prohibit apps from creating +x files. But the cost of doing that in the existing ecosystem is enormous.
In fact I'm struggling to think of a single file type that truly won't have a use in emacs.
(It might actually make more sense to forbid editting executable files than going via type)
-----
>There's a lot more nuance in existing systems (SELinux) and potential future systems than just "allow everything or nothing".
The problem isn't that there isn't a lot of "nuance" in these systems, the problem is that there is!
Sure, SELinux will work if you have a static system or an SELinux expert under the desk.
Creating a system that works and remains understandable is much harder.
If you want to push this further, you could imagine a permission system that can distuingish based on file types. Gimp overwriting a PNG is probably intended, Gimp overwriting a bash script probably not.
There's a lot more nuance in existing systems (SELinux) and potential future systems than just "allow everything or nothing".