If duplicate hashes would cause an issue, you might as well just use a cryptographic hash function. For a non-specialist it's quite hard to evaluate the space of non-cryptographic hash functions. There's so much more documentation and information available for cryptographic hashes compared to everything else.
And you need to be sure that the properties you're trading off are really something you don't need. Using a cryptographic hash is much simpler, has fewer ways to going wrong and usually isn't that slow anyway.
To your first point: it’s not a bulletproof arrangement, either. PbKDF-hmac-sha1 can produce duplicate hashes if the input is larger than the hash block size. The special case is: if the input is bigger than block size, do one round of sha-1 before proceeding.
I agree with your second point, developers reach for asymmetric signatures when hmac would do, and reach for hmac when a long fast non-cryptographic algorithm would do. I _think_ its an over-abundance of caution rather than a misunderstanding of the characteristics of hash functions.
PbKDF-hmac-sha1 isn't a Cryptographic Hash Function. It's a Password Hashing Function. They have different security properties, and must not be confused. Sadly they're confusingly named.
Yeah, and it’s not pedantic. I hope a blog post nowadays points newcomers to an example decision tree for use-cases. Though we should hold this blog post to its own standards; it’s not intended to be best-practices.
And you need to be sure that the properties you're trading off are really something you don't need. Using a cryptographic hash is much simpler, has fewer ways to going wrong and usually isn't that slow anyway.