Sadly, this all could have been avoided with one simple change four years ago: rather than having the UDID match the specific device, have it be hash of the app's "keychain identifier" (usually set at the company level, enabling cross-product identification) and the real UDID. Then, it doesn't matter if an app finds out the UDID it can access: it's specific to that app or company anyway, and can't be abused as it currently is.
But as the UDID was implemented poorly (and immediately overused for everything, including from server-side account keying, which Apple can't just break), they have to essentially remove it now.
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.
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.)
But as the UDID was implemented poorly (and immediately overused for everything, including from server-side account keying, which Apple can't just break), they have to essentially remove it now.