What is the basis of the statement "12 rounds of HMAC must be reproduced / created verbatim, no known shortcuts."? No matter how many rounds you do it for, it always produces a 64 byte string. Why not just do it once? Or why not just use uniqid() as the salt if the other random generators are unavailable and forget about hashing it?

HMAC requires not only a password but a different key initialization scheme. Normal hashes like the example below can be used as "partial hashes" by saving their states, reducing time to calculate derivative hashes. This is why prepending a salt to a non-HMAC hash is foolish!

A clever attacker could use the prior hashes to make each successive hash take only moments. HMAC

For an attacker to programmatically derive our resulting hash they must be able to know/predict the result of uniqid and must also know the key used to encipher the hash. If they only compromise the database and know we've used this technique their only chance is to brute-force the resulting hash.

For an attacker to brute-force our resulting hash they need to know what is hashed in the final iteration, and what the key is. Naturally, if they compromise your filesystem too this is already known. However, even then they must know the penultimate hash plus the result of the microtime call!

Then all they know are the random bytes used as a salt for the BCrypt hash... but then, they know the first ~11 characters of it anyway.

I'm a bit confused about what you're saying here, especially since there are multiple hashes being calculated and you don't define which one you're talking about. My point is that the result of hash_hmac() is not used to hash anything sensitive at all. The result of that function is It is only being used as a salt and is stored in plain text. Even if a malicious hacker were to somehow determine the original uniqid() or key or microtime() used with hash_hmac(), this gives them absolutely no further information in order to determine the result of the password hashing with crypt(), which is why I cannot see any benefit of using some complicated "random" hash over simply using uniqid() as a salt for crypt().