I don't think people fully appreciate just how bloated and inefficient the modern web has become, so let me give you a concrete example.
Let's say a site wants to include a Facebook "Like" button. So loads a script from Facebook that spawns the button. But it's not that simple.
The script to power the "Like" button (which has to retrieve the current number of likes and then also submit an authenticated user's like) can't run on the site hosting the Like button. First, there are the security concerns--a user's Facebook authentication cookies are restricted to facebook.com, so the site hosting the button has no access to them. And there are other security and privacy implications of having that user's Facebook data transit through that site, so we want to avoid that. And there are technical concerns, too, with having Facebook's script run directly on that site--what if there are compatibility issues with other scripts on that site?
Because of these reasons, the Like button spawning script is actually very simple and very basic: It just spawns an IFRAME (inline frame). Remember those good old Web 1.0 days when sites had frames? It's like that, except these frames can be tiny and exist in the flow, right in the middle of the page. This IFRAME contains the Like button. This way, the button itself and all the scripts associated with powering the button are still on facebook.com, and they run in the context of facebook.com--they're just inserted into the host page like picture-in-picture TV.
On the browser side of things, each IFRAME is treated like a separate webpage that the browser has to open. It has to be since that's the whole point of the IFRAME. This means that each IFRAME has its own DOM. Its own presentation context. Its own security context. Its own private JavaScript sandbox. And you know what? These things are not cheap! And each IFRAME loads and executes its own JavaScript, and if the function of a Like button involves a hefty JavaScript library, then each IFRAME gets its own copy of that hefty JavaScript library.
So if you load a page that has a dozen of these social-media doodads (everyone does it like this, not just Facebook; I don't really want to single them out), then it may look like you have just one tab open, but behind the scenes, it's a lot more like having a dozen tabs open.
And this is part of the reason why some sites are now shying away from these IFRAME-based things. For example, in the latest iteration of the New York Times website, the Facebook button isn't an inline Like button, but is instead something simpler that just pops up a separate window for you to do your social media thing. To the end-user, it doesn't look all that different, but there is a HUGE difference in the underlying footprint of the implementation.
There are other types of bloat on the modern web, some similar, some different. This is just one example of how something seemingly mundane that everyone has encountered at some point is actually quite monstrous under the hood.
Also, when I use NoScript, I check the option to "temporarily allow top-level sites by default" and select the most permissive suboption ("base 2nd level domains"). This makes NoScript a lot easier to use since, most of the time, the abusive and excessive JS are third-party, so it's a nice way to reduce the amount of manual whitelisting that I need to do. And this also lets me keep site like facebook.com out of my whitelist--this way, Facebook's JS works when I'm browsing Facebook, but it won't work when I'm on some other site, which prevents the Like-button-bloat detailed above.
Facebook
Twitter