In cryptography, hashes are often used as place holders for the original message; by using the hash, we are effectively using the original message. For example, when signing a long message, we hash the long message and then run the signature algorithm on the hash; if we assume that the signature algorithm is strong (and so only a message that generates that hash will validate), and we assume that it is hard to find a second message that generates the same hash (so that it must be that original message that was signed), then the entire system is strong.
As such, we generally don't consider 'information leakage' when talking about hash functions; that is, we generally don't worry whether examining the hash output would leak information about the original message. Instead, we worry about the difficulty of finding a message that generates that hash (either preimage resistance, second preimage resistance or collision resistance), because that directly relates to the security assumptions we commonly need from hash functions.
That said, if someone were to find a leakage in (say) SHA3, for example, by examining the hash, we can determine the length of the message, well, that'd be quite worrisome (and we'd likely start deprecating SHA3); we sometimes want to treat our hash functions as a random oracle, and that would indicate that it doesn't act like one [1]. However, the prospect of such leakage would appear to be unlikely.
[1]: Yes, I know length extension attacks show that SHA-2 doesn't act like a random oracle; that is well understood, and we just avoid using SHA-2 in a way where that specific attack is applicable.
