The hash IV values aren't provided to the user for the simple reason that they are not required.
The whole idea of a hash function is that you get a practically unique value that is irrevocably linked to the input message without exposing any details of the message. Using an IV would go against this idea: it would give you a different value each time the IV is changed.
This is not the case for ciphers, which require randomization to be CPA secure. If they wouldn't then repeating messages would be identical for the same key. You could for CBC of course start with an in the plaintext, but that would mean that the ciphertext would always have to be expanded. This could be wasteful as there is no requirement that the IV is send with the ciphertext.
This shows another reason why not to include an IV in the interface of a hash function. If a unique value is required you can simply include it with the message. It will only be included in the hash calculation rather than expanding the output of the hash.
Now there are actually reasons where having different constants is beneficial.
One is when a shortened hash value could leak information about the full or less shortened hash. For instance, if an adversary has a SHA-512/256 hash then the adversary would also have the first part of the SHA-512/384 or SHA-512 hashes. For that reason these hashes do actually have different constants.
Another reason is when hashes are used 1. with the same input and 2. for different purposes. In that case it could be beneficial to have some differentiating bits included in the hash. This is a scheme that is actually present in SHA-3, where a KMAC algorithm and the SHAKE functions use a few different bits than the raw hash algorithm.
HMAC doesn't have this kind of protection. It does however use the key in two different ways so you'd have to create a pretty weird scheme to ever get into trouble by hashing a key, message and duplicate a HMAC result.
Modifying these constants should not affect the algorithm at all. If you however use your own constant values then people might get suspicious that you know more about the algorithm than themselves. You're better off using the original constants as "nothing up-your-sleeve" values.
If you need additional input of some kind, just make it part of the message, making sure that the encoding of the message is canonical. That is, make sure that different fields in the message can be distinguished, e.g. by prefixing the length before each field.