Actually, it's more about the security paradigm rather than the actual security.

When we talk about the security of a cipher (e.g. randomly keyed AES), we want to express it as "there's no fast program that can distinguish AES encryption from a random Oracle (that is, one that generates random ciphertexts in response to any query)".

That works out nicely (and we can use that assumption to prove the security of things which use that cipher). However, when we look at a single hash function, well, there does exist a fast program that exhibits a collision - it just outputs two preimages that happen to collide.

Now, we don't know what that program is (because we don't happen to have two such preimages on hand) - but it still remains that the program exists.

To talk about hash functions in this paradigm, we talk about hash function families, which avoids this simple counterexample.

Actually, it's more about security proof techniques rather than the actual security.

When we talk about the security of a cipher (e.g. randomly keyed AES), we want to express it as "there's no fast program that can distinguish AES encryption from a random Oracle (that is, one that generates random ciphertexts in response to any query)".

If we take that as an assumption (and it certainly looks like a reasonable one), we can use that to prove the security of things that use that cipher. Hence, that is a useful paradigm.

However, when we look at a single hash function, well, there does exist a fast program that exhibits a collision - it just outputs two preimages that happen to collide.

Now, we don't know what that program is (because we don't happen to have two such preimages on hand) - but it still remains that the program exists.

To talk about hash functions in this paradigm, we talk about hash function families, which avoids this simple counterexample.