Can still block them with element blockers. Elements are quickly cataloged, added to block lists and shared. Happens in mere minutes. A lot of this is automated, but it can be hand curated as well for some that were not noticed or perhaps new. An entire "industry" exists to keep the web clean. uBlock Origin does a fantastic job in this regard. In fact, it's one of the only methods that kills adblock blockers. I've not seen a successful adblock blocker since using it. It kills them dead. No more nag screens. Nothing but a clean content-only website, as nature intended.

There are some very smart people in the blocking arena. Since most of this stuff is delivered via JS, it's fairly trivial, at least at the moment, to handle same-domain ads. The game may change in future, but the adblock people usually prevail.

One idea I have if the sites start outright blocking blocking users, is to sort out how to write the ads to a form of /dev/null while making the site think they've been shown. I used to do this with Flash cookies/LSOs. I wrote them to /dev/null so I could take advantage of Flash back when it was a thing, yet have no LSOs on my machine to track me. Coupled with referer blocking, history blocking, no fingerprinting, and other settings, it worked a treat.

I'm willing to bet that if we cannot "block" them as part of the domain, we can sort out a way to block the element, shunt the ads into the bit bucket and continue on our merry.

>One idea I have if the sites start outright blocking blocking users, is to sort out how to write the ads to a form of /dev/null

I think several dns-based ad blocking programs can do this today, but so far I have not had a problem with returning NULL address (0.0.0.0). Pihole talks about the pros and cons of common approaches: https://docs.pi-hole.net/ftldns/blockingmode/. One downside is you have to run a webserver to catch the redirect and all the overhead that comes with it.