There are a couple of answers here. The first one -- purely logistical -- is that without a way to bypass SNIP every developer in a team would need access to the corporation's private key (the "crown jewels" so to speak) in order to build and test their software. Obviously this isn't very good because the "private" part of "private key" means you lock it away somewhere very safe and don't share it with anyone. So even without turning security off altogether, an Administrator can disable strong-name checking for any keys that they like and "fake" the key by delay-signing their assemblies.
More importantly though the point of SNIP is not "to allow the developer of a component to block callers that even the administrator of a machine may otherwise trust." You cannot block the administrator from doing anything! Even if you could absolutely block SNIP spoofing at runtime, any user (not even an Administrator, but a normal user!) can just remove the LinkDemands from the assembly and re-compile it with ILASM (ildasm /out=foo.il / Notepad foo.il / Delete all SNIP LinkDemands / ilasm foo.il).
And it doesn't even matter.
Because your code isn't hiding any secrets or performing any miracles.
Think of the CLR Security System as being like a super-duper police force for managed code -- one that actually prevents crimes from happening in the first place rather than just solving crimes after the fact. This police force serves two purposes:
·It stops the bad guys from doing bad things; and
·It keeps the good guys honest
But what happens if you get a corrupt policeman on the force? They can start committing crimes themselves, or they can let other people get away with crimes. Or worse, what if you have a corrupt government controlling the police force and actively turning them against the honest citizens of the world?
Bad things can happen.
So too if you let in highly trusted "bad" managed code (a corrupt police official) or -- even worse -- if you run malicious unmanaged code (the corrupt government that has control even over the police force).
So what's it good for? The main usage for SNIP is when you want the semantics of an internal class or method, but for one reason or another it needs to talk across assemblies. Perhaps the method needs to be exposed, but you do not have enough time to fully test or document the method for arbitrary 3rd party callers, so you put in an SNIP so that people don't call it by accident. Maybe you license your technology in a certain way and don't want your customers building their own applications on top of your code, so you put in a SNIP to gently "remind" them that they shouldn't be doing that if they ever "accidentally" try to reference your component. (And then you get the lawyers involved if they intentionally violate the license).
But putting a SNIP LinkDemand on your code will absolutely not stop a malintentioned person from calling your code if that's what they want to do. Physical isolation will stop them, but then if you don't trust the administrators of the server then give up already; they can do far more damage than call your internal APIs.
(Also: "There is a big difference in the levels of both expertise and effort required to scrape or modify in-memory bits vs simply using documented and supported reflection methods." Agreed, but using script is even easier; who wants to bother with reflection? And I covered that argument ).