Why are we blocking DNS over HTTPS again?

I understand the underlying premise for Netskope's recommendation for blocking DNS over HTTPS, to mitigate exfiltration risk, etc. However, with the industry push to move to DOH, won't we need to allow DOH traffic at some point? Most of our users browsers are configured to try DOH first, and some of them seem to be running into issues if DOH is not available and falling back to traditional udp 53 fails.

I also don't understand why Netskope says they don't support DOH traffic steering. (See https://docs.netskope.com/en/netskope-help/data-security/real-time-protection/best-practices-for-real-time-protection-policies/best-practices-for-utility-policies/#recommended-utility-policy-2-1) It would seem Netskope DOES support it since we ARE steering DOH traffic to Netskope, Netskope identifies the DOH traffic, and then blocks it with the Block DOH real time protection policy. So what does Netskope mean when they say "DNS over HTTPS is not a supported protocol for Netskope steering (CASB/NGSWG/NPA)"?

With the push toward DOH, you would think we would want to allow DOH traffic steering, have Netskope decrypt it and inspect, then be able to identify and alert on anomalous behavior within the DOH request packets. I'm sure there are technicalities I'm unaware of here, so could anyone clue me in on why this apparently isn't possible?

And like many other customers who have shared in a separate post out here, the thousands of DOH block alerts we are receiving every day in our Skope IT alert log makes it impossible for our security to acknowledge them all, and this drastically skews our reporting. Filtering out DOH from the Alerts view is not a helpful solution.

Thanks