"Your site is slow, so we'll break your functionality. There you go, isn't it faster?"
It's not the browser's fault that a badly written page loads slowly. Has the speed competition become so important that browser vendors would rather load a non-functional page than a slow page?
It is not. It is a simple way to load scripts from JS with browser forcing serialization of the script exectution.
It should be developer's decision to choose whether he prefers speed or simplicity in a given context.
If your site is unfunctional without JavaScript, it is already broken.
If you use JavaScript for progressive enhancement, then not loading scripts on a slow connexion is a great idea.
And no, it's not for a web site author to decide to require JavaScript when his functionality doesn't require it: if he does that, he's simply wrong.
I completely agree, but if I configure my agent to break some assumption you made in your code then I have no one but myself to blame.
One can break just about any piece of software by messing with the environment in which it runs. It's a shame that we rarely check or document these kinds of dependencies.
This is really just checking for capabilities before using them and checking return values for errors, which everybody should be doing anyway. Assuming JS (or any browser feature) is available is similar to skipping the check for NULL after calling fopen(3). Skipping error handling is an indicator of shoddy programming.
Graceful degradation works well enough that you can usually get what you want from a web page even if some of the JS is broken.