we would never know if one is capable to easy reverse hashes
We know today that reversing hashes is impossible and will always be. If you know that the hash is 4, and your hash function is mod10, then you can use 4, 14, 24, 34, 44, ..., and you will never know, which value was hashed. You could know that only in one case: if you would know some properties of the hashed data. So, if you know that some ASCII string is hashed, then it may be possible to prove that this particular 256-bit hash will only match "Hello World", because nothing else is matching ASCII values (or nothing else is in your "dictionary"), and you can try to prove that, based on context. But if something is totally random, for example some private key, some signature nonce, things like that, then you will never know, what was really hashed, and what was recovered as a second preimage.
Why rely on a single hash function?
I think the answer is quite simple: because using two or more hash functions can make the system more complex, and will not make it more secure at the same time, so it is not worth it. But as I described, you can do it yourself, if you really want. You can implement it, you can promote it, you can convince people to switch to things like that, but I think the consensus will be formed around single hash function, unless something serious will be broken (or will show some serious weakness). Also, to add something more to SHA-256, you have to know, how it can be attacked, because you don't want to add mod10 and other useless hash functions when they are not needed and can be as "broken" as SHA-256, so it may turn out that for example SHA-3 is even worse in case of some particular attack vector, that's why it should be attack-vector-based, and not randomly picked.