Constant-time comparisons of password hashes are a regular feature of password hashing discussions, mostly because timing attacks are one of the few crypto attacks that developers can get their heads around immediately. But they're practically irrelevant to password hashing†. It does not matter if you use a constant time comparison for your password hashes; to see why, try to design the actual timing attack on the password hash compare (if you've never done this before, start by demonstrating to yourself that you can design a timing attack against an HMAC comparison).

The OWASP site's password storage guidance is particularly bad, and I recommend that developers avoid that page altogether. The page began as a litany of very bad advice (reversible encryption, salted hashes), and when it was pointed out that secure password hashes like scrypt were the right answer, the authors decided instead to "teach the controversy". OWASP is very political, and not managed by computer scientists.

† The post we're commenting on inaccurately says that the hypothetical timing attack it describes has been done before, but links to Boneh's TLS timing attack paper. My guess is that the password hash attack the author was considering has never been tried; among other things, it stipulates a password hash oracle for the attacker.