I'm talking about Apple, not about developers. If Apple had returned SHA1(KeychainID + UDID) instead of just UDID when the SDK was released, then apps would never have seen the "real" UDID, and we wouldn't have this issue now. However, since Apple did not do that and they can't change the UDID now (for a variety of reasons, including various abuses of it by developers), it's too late for them to fix it now with such a simple change.

They certainly could still add a new API which does something along the lines of what you describe while still deprecating the UDID API. The only real catch is that they'd had have to do it in such a way as to make it difficult to figure out the un-hashed UDID from the value they give you. It's certainly possible to do that, though. For example, instead of hashing the UDID along with the keychain identifier, they could hash it along some other app-specific or vendor-specific info which only Apple knows and is not shared with developers.

If a company can reverse engineer sha512 that easily, we got bigger problems that leaking device numbers.

And that company sure as hell isn't wasting time developing iOS apps.

No reverse engineering of SHA512 or other hash algorithm is necessary. Left as an exercise for the truly curious about security. (Hint, you can get the same information from much lower hanging fruit.)