A hash may be invertible if it contains at least as many bits as the input (though it is not is major usage where this is geenrally the reverse). But the arguments are the same: you just want a perfectly flattened distribution of bits in the result, and for using it as an encryption, you must ensure that there will NEVER be any collision (so the distribution is almost perfectly flattened with collision lists for each hash value being either 1 or 0, a property that a good hash algorithm should have as well when their input has the same (or smaller) bitsize as their output. But actually a good hash will want to have this flattened distribution even if you truncate the hash value to less bits (the same will be true if you use it as an invertible encryption that must be secure, i.e. where you cannot guess the decryption key if you konw some pairs of clear-text input and resulting "hash" value, which should still be invertible but only when you know the decryption key or when you can generate it easily because you know the encryption key). Many encryption algorothms also depend a the existence of a "securely strong" hash key (at least to generate the encryption/decryption keys), and the inversible operation of encrypting/decrypting may as well be used as a hashing function (once you give it one of the keys). Note that encrypting very short messages even with a very strong encryption algorithm with long keys causes a major problem because the result is no longer a flat distribution; that's why strong encryptions require padding those messages with enough bits so that they become longer than the minimum length required for the keys. Such padding are not random, but they cannot be static (e.g. all zeroes), but should be generated by a strong hash: very short messages will then become undistibuishable from long messages that have the desired flattened distribution of bits in their encrypted patterns.
