As a user, I would tend to agree; but as a developer, thinking about "what if the browser decides to kill this one script request but run the rest of the scripts?" is the last thing on my mind. I don't know, maybe I'm a lazy dev[0], but when you consider it's essentially the browser's selective compliance to the standards, how far down that rabbit hole do you want to go?
Now, you could argue that requests can legitimately fail at any time, and it's best to handle it. OK, as a lazy/efficient dev willing to entertain that, I'll design my page to put up a modal alert saying "There was an error loading this page. Click OK to refresh." if anything fails to load. Now my error-handling job is done, but privacy-conscious users will still be mad at me, demanding that I gracefully degrade for every combination of request-blocking (or in GP's case, request-tampering!) they can dream up.
Again, I'm sympathetic as a user, and I've even experienced broken pages due to Ghostery, but as a developer it's hard to blame them.
[0] And AFAIK have no hard dependencies on third-party scripts like GA.
This is why I think the concept of soft and hard dependencies is useful.
As a dev, it's nice that I can track what my users are doing with GA, but I would rather my users be able to use my application. This is definitely a 'soft' dependency because I do not have a hard requirement to use its functionality. If a critical piece of my application (a 'hard' dependency) fails to load then that is a bigger problem.
I don't think we have to degrade gracefully for every possible failure, but failing to render anything is a really bad failure mode. Your lazy/efficient dev is actually just providing a good user experience; if something bad has gone wrong, let the user know so they can refresh etc.
The thing about third-party scripts is that you have no control over them at all. By their nature, you can't even bundle them (that is a workaround for some options though)!
If your users are deploying your web-app behind the firewall, and outbound requests are blocked, if you don't handle these requests failing then the entire app becomes unusable regardless of if they use ad blocking or not.
Yeah, I got a little carried away ranting. It's probably reasonable to make sure your page works if GA doesn't load. There may be other third-party scripts that the developer views as essential but the user doesn't.
I found this searching for "google analytics stub": http://ejohn.org/blog/fixing-google-analytics-for-ghostery/ . Supposedly Ghostery was already stubbing it in 2013. They might be missing some stubs for certain scripts though, because I've had something break 6-8 weeks ago, and it worked when I disabled Ghostery and refreshed.
Now, you could argue that requests can legitimately fail at any time, and it's best to handle it. OK, as a lazy/efficient dev willing to entertain that, I'll design my page to put up a modal alert saying "There was an error loading this page. Click OK to refresh." if anything fails to load. Now my error-handling job is done, but privacy-conscious users will still be mad at me, demanding that I gracefully degrade for every combination of request-blocking (or in GP's case, request-tampering!) they can dream up.
Again, I'm sympathetic as a user, and I've even experienced broken pages due to Ghostery, but as a developer it's hard to blame them.
[0] And AFAIK have no hard dependencies on third-party scripts like GA.