Client-side password stretching - danger of the salt being public? In case of using client-side password stretching (plus a single hash on the server) - the server would need to send the salt before authentication, of course.

Though the salt is not considered a real "secret", is having the salt that public a serious consideration for rejecting this method (i.e. client-side password stretching)?

This answer (with more than 600 upvotes) says it's important to keep it secret. I know it's difficult to measure how important something is, but if you could give me some idea, that would be helpful. The reason to do it client side is to mitigate DDOS attacks.
Though the salt is not considered a real "secret", is having the salt
  that public a serious consideration for rejecting this method (i.e.
  client-side password stretching)?


Yes, it is better if the salt is kept secret, but the attacker still has to perform a full-on offline brute-force search even if they know the salt before a breach, it's just that this search can be carried out before a breach and then after a breach only a logarithmic effort per entry is needed for the lookups. And if they don't learn the salt, the "timer" at which brute-forcing starts is pushed back to the point where the database leaks.

Now this exact attack, the ability to pre-compute real-salt-based password hashes before an actual breach is part of the reason why OPAQUE, the current state-of-the-art asymmetric password-authenticated key exchange (aPAKE) exists, as no previous aPAKE defended against this kind of attack.

So TL;DR: Hiding the salt is better, but actually doing so may be considered too much work and it's not the end of the world if the salt leaks.