Why are you even running scripts from a third party on your own site?
If the ad is a static image, use an <img> tag. If it's text, show the text. If it's a video, use <video>. If they want to run custom code, tell them to get lost.
Yeah, it's ultimately the ad networks' fault, but what did you expect?
The way it usually works (or at does at least for 'us', at Australia's largest media orgs) is we have our own ads library, we'll communicate with our trusted ads network, and it'll find an ad 'provider' who might have about 10 possible ads for that spot. We'll insert an iFrame into the page and then insert their JS into the iFrame, which will then load the one ad to display.
This way it's a little bit more than just dumping a random script into the body. However, I don't do much with ad serving so I'm not sure exactly what there is technically to curb the iFrame interacting with the parent site (apart from extra console.log statements)
Because it's an ad network and a script tag is how you pull the creative into the page. The whole point of using an ad network is that you are letting a 3rd party handle the management of your inventory, the ad creative is unknown until when the call is made.
It just isn't practical once there were millions of websites that you would negotiate media buys with them individually and send them some image assets or text ads that they would then have to host as a 1st party.
You also have to factor in all the things ad servers are designed to do like control the number of impressions shown, track views, clicks, and interactions, as well as allow advertisers to rotate new creative in on-the-fly.
If the ad is a static image, use an <img> tag. If it's text, show the text. If it's a video, use <video>. If they want to run custom code, tell them to get lost.
Yeah, it's ultimately the ad networks' fault, but what did you expect?