Their docs link to this explanation, in which the link I give uses an example that appears to be identical to the HA implementation - https://blog.cloudflare.com/validating-leaked-passwords-with...
I might be misunderstanding, but if the first 5 digits is a unique hash in the HIBP database then an attacker can replay that request, then lookup the hash. But "When hashes are grouped together by a Hash Prefix of 5 characters, we find the median number of hashes associated with a Hash Prefix is 305." {ibid}.
If you've acquired leaked passwords as HIBP have, you then just make hash lookup tables, then you have 305 potential passwords to try, or try and whittle down. If the bucket of hashes has "hunter2" in it, for example, then that's perhaps a good one to try - https://blog.cloudflare.com/validating-leaked-passwords-with... is worth reading.
according to that sharing a part of the hash is a risk. it could for example end up in logged urls somewhere. it's a pity that the argument revolves around absolutes ("this is bad", "no, it's not") instead of actually investigating and explaining why they see a problem here.
Imagine if your smart toilet would just send a small anonymized message to a urine sampling analysis service so it can let you you know your cholesterol levels are a bit high, totally anonymous, totally for your benefit. Maybe it's a great feature, but would anyone expect this to happen without consent / opt in?