Is there a threshold of bits of entropy below which hashing becomes meaningless?

For a login function, you should aim to get the hashing process to take around a second.

If you take this post as a guide, 1170ms requires around 8,192 iterations of bcrypt (cost of 13).

This means that your iterations add around 13 bits of effective entropy.

If you have only 31 bits of entropy in a secret, hashed value, then this bcrypt configuration would give you 44 bits of entropy.

As a guide, 47 bits of entropy would take 0.223 Hours maximum to crack per phone number (assuming at 350 billion guesses/Sec). Even if the attacker didn't have these type of resources and they guessed at 2 billion guesses/Sec using a single home PC, this would take 39 hours per phone number to crack.

So, to answer your question, it doesn't make sense when you either need to increase the hashing time to an unacceptable level (a cost of 16 to add 16 bits would be over 9 seconds, what you would describe as harmful to your application), or that the cracking time per secret is below your goal for the sensitivity of the information it is protecting and the resources of your perceived attacker.

If it is acceptable for each phone number to take 39 hours to crack by a casual attacker, then there's no problem with bcrypt at a cost of 13 . This is assuming they are using bcrypt with said cost and not simply storing SHA1(salt + number).