Why avoid custom HMAC implementations like the following? H (o_pad || H (i_pad || m, static_salt), static_salt)

Where the Hash algorithm used is SHA512-crypt: https://www.akkadia.org/drepper/SHA-crypt.txt

What if an attacker knows the o_pad, i_pad, the static_salt, and the final HASH but not the message... it's potentially possible obtain the message (other than just brute-forcing it) using this custom implementation?
You need to be clear about the interface and security goals of what you're trying to achieve, vs. those of HMAC.  This passage of your question seems to state your security goals:


  What if an attacker knows the o_pad, i_pad, the static_salt, and the final HASH but not the message... it's potentially possible obtain the message (other than just brute-forcing it) using this custom implementation?


But that's neither the interface nor the security goal of HMAC:


Interface: MACs are secret keyed functions; they take a key and a message as argument, where the message may or may not be secret.  You're describing something that takes a message and no key; it's not the same interface!
Security goals: MACs expect the key to be a secret random value, and allow (but not require) the message to be non-secret; the goal is to resist forgery of message/tag pairs.  In your construction, on the other hand, you're assuming that messages are secret, and that an attacker who knows every other value (o_pad, i_pad, the static_salt, and the hash result) must not recover the message.


So you're asking us to do an apples-to-oranges comparison.  And in addition, the goal that you have in mind—inability to recover the message for an attacker who sees all the other values—is already a goal of SHA512-crypt.

I hope this isn't too harsh, but what you're doing basically is adding some extra complexity on top of SHA512-crypt that doesn't do anything to further the goal that you've set for it, and superficially resembles HMAC.