There is a very good use for them: their existence proves that the distribution is uniform. Anomalies in the results would indicate that something is wrong (like, for example, very difficult to notice bugs in the code, resulting in incorrect hashes).
That's how I confirm the bruteforce is working correctly, indeed.
Also, I don't see the point of saving keys that have some 0-bits prefix. It saves some kernel instructions to simply skip that check, and use the hash target itself as PoW evidence.
I don't see how checking against 0 gives anything better/worse than checking against target ?
Which kernel instructions do you skip checking against the target ? You would still have to do the CMP. Sure you can mutualize the first 32 bits to check, but then you need to check a subset of the next 32 bits and you're introducing complexity, branching, etc...
If anything checking against zero frees the compiler from the dependency to the target registers on this instruction.
That being said, my biggest issue with Puzzle 69, 71, etc. is that it is impossible to validate that the GPU computes ALL the data correctly (what if a bit flips due to cosmic rays? impossible to know, unless each and every hash is verified); so if I'd be Bram, I wouldn't be so brave. I see too many points of failure.
Since I have a gazillion prefixes from 68 I can tell you that statistically speaking the odds of a bitflip or compute failure is extremely low. And dwarfed by the odds of a competitor finding the key before us. So it does not really matter in the financial modeling. Also about 40% of the GPUs have ECC.