I am not sure. But seems like the nature of the encrypted connection and the stream utilisation (akin to HTTP/2) would make it harder for something like e.g. your home PiHole to block ads at the DNS level -- or any other lower-level in your network before stuff hits the browser.
I should have worded my comment better. It wasn't a claim, it was more like a "I think Google wants this protocol to succeed for their own ulterior motives (serve ads and impede blockers), but is that what is actually going to happen?".
I mean, not directly. The ad team didn't get a team together and say "make a protocol that will get our ads to the browser quicker", it's likely a team made to "make the internet faster by solving problems with TCP", and it just happens that A. they're funded by ads and B. this speedup also happens to work in favor of ad delivery. Same for the other parts of the internet, like dynamic content [chrome, JS] and OS speed [android], they're making the entire internet faster which ends up including how fast they can push an ad.
You can't do much at the DNS level if everything comes from "google.com". Which seems to be where Google is going with this. One big multiplexed encrypted pipe between their browser and their servers, containing many streams. All pages are hosted by Google via AMP, all ads are hosted by Google, all tracking is performed through Google Tag Manager, and the power of add-ons to Google's browser is limited to prevent ad-blocking.
