Well, in cases where you can't trust the client, that means you (the server) should not allow any client side code that isn't heavily checked and double-checked. GP is concerned about client side security.
Of course, as it stands now, there is no trivial way to prevent what RMS wants; user-specified client-side code. But if a third party is able to specify code for the user (using phishing techniques, etc;), therein lies the security hole.
The only way to really do this is to do away with javascript altogether, and create some new mechanism that either implements what RMS is talking about, or is able to run as totally black-boxed client-side code. The former would put the client at risk to dropped-in malicious code, whereas the latter is still vulnerable to persistent hacking (meaning again, that server still can't trust the client). I would argue that the former is more secure overall, since the latter seeks security in obscurity.
Personally, I'm all for an easier way to use your custom drop-in replacements for web page code. It would be like Grease Monkey, and people would stop complaining whenever Popular Social Website changes its interface yet again. Plus, it would make sense to use some local cache for Popular Social Website's code (which would be periodically updated, of course).