In that scenario, it's on the ISP to clean their network of abuse, the same thing they would need to do if Gmail had blacklisted their IPs for spamming. After all, an ISP that can't connect to YouTube isn't going to stay in business for long.
People have been begging ISPs for ages to do a bit of egress filtering, for example, to prevent source address falsification. They've demonstrated time and again that they don't give a crap unless it affects their bottom line.
OK, but how should an ISP distinguish a good HTTP/2 connection from a bad one (I'm talking about this particular attack)? As far as I can tell, the DoS starts after the connection from bot to server is established, at which point the connection is fully encrypted. Should all ISPs MITM their clients to ensure that all traffic is good and proper?
Ever had your droplet suspended for using a vulnerable WordPress plugin?
Your droplet suddenly tries to log into somebody else's server 10 times a second. The target of the attack complains to DigitalOcean, "hey, one of your customers is trying to hack me!" and attaches a log of the login attempts. DigitalOcean assumes that the report was made in good faith, forwards it to you and immediately suspends your droplet. It won't be reactivated until you reply with evidence that you have at least tried to clean up the problem. If it happens again, you won't get off so easily.
I suppose that a similar system, in a more real-time fashion, could be set up between the maintainers of the blacklist (Google, Cloudflare, Amazon, etc.) and the ISPs. No need for the ISPs to sniff on everyone's traffic if they can rely on good-faith reports from the lion's mouth that somebody from port 52384 on 11.22.33.44 is DDoSing a Google property. Even with CGNAT, the port will identify the customer responsible.
People have been begging ISPs for ages to do a bit of egress filtering, for example, to prevent source address falsification. They've demonstrated time and again that they don't give a crap unless it affects their bottom line.