As I understand it, DoH in itself cannot be blocked by Pi-hole.
Pi-hole is build to handle DNS requests only, and as such, it never sees anything else than DNS requests.
This is achieved by configuring your router (or your Pi-hole, if you chose to setup your Pi-hole as your local network's DHCP server) to tell all machines in your network to use Pi-Hole as DNS-Server. This instructs all your machines to direct their DNS-Requests (UDP/TCP port 53) towards your Pi-hole.
All other requests are not handled by Pi-hole, but rather by the client and your network's router/gateway (before the requests leaves your local network).
As DoH is using HTTPS (TCP port 443), Pi-hole will never see those requests in the first place.
So the most efficient way to block DoH would seem to be blocking DoH at your local router/gateway level (which likely would involve additional hardware like a custom router that can be tailored in such a way).
But alas, there would be no way to reliably distinguish DoH-DNS queries from normal HTTPS requests without inspecting packets, and inspecting packets would mean to somehow compromise and break HTTPS encryption first. In addition, doing that in real time would quite possibly involve a more beefy piece of hardware than the Pi Zero that is currently handling my DNS, even a Pi 4 might fall short here.
Possibly the only leverage Pi-Hole could use is to block access to domains whose sole purpose is likely to provide DoH services. i.e. by blocking the traditional (port 53) DNS lookup of a known DoH server.
But note that by employing HTTPS as transport protocol, ANY webserver could receive and directly digest or forward DNS requests. E.g. technically there is nothing that would stop Google from accepting and processing a request like 'https://www.google.com/dns-query'. Trying to block DoH by blocking the associated domain thus may result in loss of access to the very content you are trying to get to.
I see further shadows lurking when employing DoH with regards to phishing attacks (they can hide all the more comfortably in an HTTPS data stream) and the reliable authentication of trustable DNS servers - if DNSSEC isn't applied in conjunction with DoH, it'll be all the easier to spoof and redirect valid domains to malware sites, being indistinguishable within the browser, all possible by shifting DNS from a network to a client-side feature. I fear chosing DoH over DoT (which was also discussed and tested by browser makers last year) has to do more with Pi-hole, Blokada and similar DNS-blockers gaining momentum outside the internet's geeky corner than the (also somehow valid) increase in privacy. Security-wise, DoH might turn out to be a painful experience for most network admins.
But I've drifted a bit off-topic, sorry
For now, Pi-hole users could try adding DoH servers to their block lists should they wish to thwart DoH.
Fortunately, this should work out of the box, without any need to alter Pi-holes current implementation - granted the known DoH domain names find their way in some well-maintained blocking lists.
But protection or blocking success will never be as complete as without DoH, as DoH is shifting the very mechanics of DNS resolution away from the network to the client. If this shift is to become widely accepted in the future, network wide DNS blocking will become very hard to achieve for anyone, not only Pi-hole.