And links to lists of what is blocked:
I'm curious to know what the in-the-wild breakage rate for FF's blocking feature is. I use Ghostery myself and I find that maybe 1 in 100 are broken. I feel like that could be 1 in 1000 if blockers implemented a Google Analytics stub -- by far the most commonly required script for things to work.
In the situations I've seen, the issue was using GA without first checking it loaded correctly. Defensively coding third party requests, let alone all requests, should be second nature.
It raises two questions for me:
1. Is there some code out there being copied everywhere which assumes GA will always load?
2. How do I make sure this is never an issue in my projects?
I don't think (1) is an actual problem, and I don't know of any options for (2).
Bandwidth throttling doesn't directly help, although it may make it obvious which third-party scripts block the render of the page (which often seems related).
Ideally you would have good test coverage on the loaded page, and then randomly block requests to see what breaks. Mark resources as either hard or soft dependencies, make sure soft dependencies never break the page/functionality of the app, and make sure loss of a hard dependency degrades nicely.
Edit: I should also add, my most memorable run in with this bug was with a very well known application, and they were very quick to fix it once reported. I was surprised none of the internal devs had run into the problem, as I assumed most would run a blocker, but it may have been an early access release...
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.
 And AFAIK have no hard dependencies on third-party scripts like GA.
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.
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.
ghostery and friends tend to break stuff more often.