Why is hashing a password with multiple hash functions useless?

The assumption always is, that any attackers will know the software used, including configuration like which hash is used. There is always a risk of that knowledge leaking, so robust systems must be safe even if their source is known. (Maybe the attacker bought the same piece of software) Also, if the attacker somehow obtains just one password, and the corresponding hash, it's relatively easy to find out which one of a set of plausible hash functions produces that hash.

As for using multiple hashes for one password at the same time, the problem is that it usually makes it possible to brute-force the hashes by just concentrating on the weakest or easiest to calculate (chosen by the attacker.)

There was no link, so I don't know exactly what situation it is you refer to, of course.

Please see this related question on why it's a bad idea to combine multiple hash functions.

If someone gets their hands on a list of hashes and he doesn't know what the hash function is, how can the passwords be cracked?

It seems that you want to defend against the case that an attacker gained access to your database, but not to your source code. Stacking multiple known hash functions isn't a good approach for this though.

If an attacker can register an account themselves, they will have a combination of password and hash, making it rather easy to guess the used hash functions. Even if they do not have this, bruteforcing your combination of used hash functions will likely be easy.

So you don't actually gain anything by just combining some well-known hash functions, and writing your own from scratch is obviously a bad idea.

If you want an additional secret from your code base instead of the database, you may consider adding a pepper, which is not only more secure than combining hash functions, but also easier to maintain that some custom (combination) of hash functions.

It might not be completely useless, but perhaps it's a little too close to two very bad ideas - namely, security through obscurity and rolling your own crypto.

Ilkkachu mentioned above that we assume the attacker knows the specific implementation (Kerckhoff's principle). If this isn't the case, then we're tempted to rely on the specifics of our implementation for security, and this creates an additional weak point. Secondly, anything that goes beyond the standards designed by experts is risky, because it's very, very hard to be sure that you haven't added any vulnerabilities.