It's whack-a-mole, but better whack-a-mole to learn-to-love-the-mole.
Another way to think of it besides the futility of whack-a-mole is, it's pushback, resistance, sand in the gears. It's making an undesired behavior less valuable. Yes you didn't stop sites from including analytics, yes tomorrow google will have some counter move, but that doesn't mean the effort was pointless. If you can exert a 5% pressure on some system and maybe only get a 5% reaction, that's perfectly fine.
They already have a counter move, to an extent. One of the deployment models for GA is via Google Tag Manager. One of the deployment models for GTM is this[1] server-side mode deployed to an App Engine container in Google Cloud. The only browser-visible communication happens between your browser and the App Engine instance, and then you send server side calls from that to the downstream systems based on those events (GA, Facebook Conversion API, etc).
It can also be used like the traditional GTM model, where it loads the primary GTM script browser-side, then that loads additional browser-side scripts based on the tags you implement (GA, Facebook, chat systems, map widgets, whatever). But the default GA support built into it avoids loading anything from Google's domains directly by the browser. And it's not even subject to the CNAME cloaking protections[2] that ITP have implemented, since it's not using the "CNAME to third party" technique that's typically common for these sorts of things to get first party access/privileges and is instead actually running on your infrastructure.
Integrating with Google Analytics on the server-side as opposed to the client-side has always been available. Developers just rarely do it because it is easier to add a JavaScript snippet to the page.
It gives much more detailed data like how long a user keeps a page open, and browser fingerprinting data that's not available server-side like querying fonts or viewport size.
Not familiar with the particulars, but server-side GA, has the same theoretical ability as the current Javascript-based GA. The only difference is that the client code is served by the first party, and not the Google servers.
What's really clever is that at the scale that GA is deployed, it's really really hard for Google to willy-nilly break API just to get around this because a lot of webmasters will simply not bother updating their scripts, and if Google forcefully pushes a breaking change, people might stop using GA, or worse, they get an avalanche of bad PR for breaking half the web.
My understanding is they are veeery careful around rolling out changes and deprecations. The cleverness is that there's a huge asymmetry in how fast Firefox can globally deploy updated shims vs how fast Google can change GA API.
It's whack-a-mole, but better whack-a-mole to learn-to-love-the-mole.
Another way to think of it besides the futility of whack-a-mole is, it's pushback, resistance, sand in the gears. It's making an undesired behavior less valuable. Yes you didn't stop sites from including analytics, yes tomorrow google will have some counter move, but that doesn't mean the effort was pointless. If you can exert a 5% pressure on some system and maybe only get a 5% reaction, that's perfectly fine.