Currently working in ad tech. Your solution wouldn’t work today because so many current and upcoming privacy solutions being rolled out across platforms are run through a VPN or VPN-like service, and many with IP rotation. Many of the bots are using these services so that their IP appears as coming from a legitimate privacy service like Cloudflare.
The privacy service providers don’t have good incentives to attempt to identify which users are bots because it would undermine their privacy claims. Tough situation.
We do think we have a solution to this but it’s unlikely to last in a privacy arms race. There’s really only one logical place this ends with the ad model surviving, and it’s not pretty.
People using a privacy service are also highly likely to be using an ad blocker, I don't think trying to identify which ones are bots is even worthwhile.
Ads that are pre-rendered by the first-party origin, embedded in the page, cannot be blocked by ad blockers, unless the ad blocker keeps a giant blacklist of rendered advertising content. I don’t know about you but I’ve been starting to see more of this kind of content. Ad blockers are a separate issue from bot traffic.
But more importantly, while your assumption is probably true today, it won’t be soon. On-by-default network privacy enhancement is coming, and already here in places. You can easily have these services in place by accident, today, without knowing the first thing about them or why you might want them.
Origin-served ads cannot be blocked by host-based adblockers, but can be blocked by hueristics-based adblockers.
I'd implemented a variant of this as banner ads began increasing in prevalence in the late 1990s / early aughts, using CSS to filter out standard banner sizes and path elements. Tools such as uBlock Origin incorporate far more sophisticated variants of this. It's also possible to block (or selectively permit) specific page elements with a CSS editor (e.g., Stylus), with web proxies (including SSL/TLS terminating proxies), or other means.
My experience is that if a site tries excessively hard to cram ads down my throat, I'll kill it and look elsewhere.
For a long time the argument was that this was a limited technically-sophisticated niche response, and that "the average person" didn't care and wouldn't bother. The increasing prevalence of ad-blocking tools and default incorporation (e.g., in the iOS platform) suggests that the barrier is knowledge and skill rather than of caring, and that people who can block ads in general will.
This itself should be a cautionary note to both advertisers and advertising platforms, as the trend will be to drive the audience bar further down sophistication and means capabilties, meaning what ad content is shown aims at less remunerative segments, and tends toward ever-increasingly noxious methods. That story ends poorly, as do most Gresham's Law dynamics.
OP mentioned blocking cloud providers but didn’t explicitly mention CDNs, and at least with AWS their IP list allows you to filter out CloudFront. I don’t know of a list of second tier relay operators for iCloud Private Relay but I do know that Fastly[1] and Cloudflare[2] were going to be participating, and presumably other CDNs with their larger number of POPs compared to most VPS providers would be logical choices to run it. So blocking only VPS IP ranges might not necessarily affect iCloud Private Relay.
1: https://www.fastly.com/blog/icloud-private-relay-and-a-priva...
2: https://blog.cloudflare.com/icloud-private-relay/
The privacy service providers don’t have good incentives to attempt to identify which users are bots because it would undermine their privacy claims. Tough situation.
We do think we have a solution to this but it’s unlikely to last in a privacy arms race. There’s really only one logical place this ends with the ad model surviving, and it’s not pretty.