Apple needs the shims anyway, even if the directory was writable. Note that the shims existed before SIP was a thing. The reason Apple needs the shims are twofold:

1. Xcode is distributed as a single application bundle. All of the developer tools are somewhere within /Applications/Xcode.app. Xcode used to be installed with a package installer, so it would dump its tools into the system directories, but a number of years ago they switched to the application distribution for a few reasons, the biggest being so it can be distributed via the Mac App Store.

2. If you don't have the developer tools installed, the shims prompt you to install the standalone Command Line Tools bundle (which goes into /Library/Developer IIRC, still as a single self-contained bundle like Xcode). Without the shims, there wouldn't be any way to trigger an installation of the standalone Command Line Tools.

> Who switches the PATH to /usr/bin:/bin or /usr/local/bin:/usr/bin:/bin?

Someone who's writing a script and wants to be insulated from potentially-malicious entries in PATH. Or shells or shell-like programs executed without any PATH provided at all, which can happen if you invoke them with `env -i`.

> Perhaps because of the same reason why on the average server it's suggested that to keep your attack surface as low as possible you only install the minimum set of utilities and services necessary for the server to be operational?

Huh? What does any of this have to do with attack surface? These tools are on the system regardless, moving them into a different directory has no bearing on attack surface.

> And you claim its system critical, yet it isn't

I don't know if you're deliberately misrepresenting what I said, or if you simply haven't bothered to actually read what I'm saying. These binaries are not critical to the operation of the system. In fact, the system doesn't ever even try to invoke them during normal operation. But they're still part of the system, and if you get rid of them there's no way to get them back without reinstalling the OS.

> and if a non-system binary is replaced and that binary is installed in a location away from system binaries you can put it back?

..what? I genuinely can't figure out what you're trying to say with this sentence.

> Not to mention that only under the current situation only Apple can supply security updates to a third party took they don't actually maintain?

Congratulations, you've just described how every third-party component bundled with the system works.

> And they can't be as quick as a system administrator who wants to remove it entirely?

That's completely nonsense. Any "system administrator" that believes these tools should be removed from OS X should be fired for incompetence. These are shims, and their entire point is to provide a predictable location within the default PATH for a bunch of tools that are actually bundled inside Xcode or the standalone Command Line Tools download. If you don't want to have git/clang/etc on your system, don't install Xcode or the standalone Command Line Tools. It's that simple.

> Because right now if you delete that "system" git the shell died t give an error that the executable can't be found but the shim gives an error? That hardly makes sense.

Huh? You can't delete that "system" git. And as I said above, it doesn't make any sense to even try, because it's just a shim. If you really don't want to have git installed on your system, don't install Xcode.

So really this pretty much boils down to "if you don't want developer tools on your system, don't install the developer tools". All that you'll have are a set of shims that offer to install the developer tools if you try and run them (which I hope you can see is a pretty sensible suggestion, and is akin to how linux distros often suggest packages you can install when you try and execute commands that don't exist).