If I understand your point correctly, you're asking how critical it is to always give different/random salts to each password?
Even if you know that hash('password', 'salt1') hashes to a a user's hash, you'd need to recompute hash('password', 'salt2') to check if it's the hash for someone else. It slows them down by increasing the amount of work. If they had the same salt it would be the same hash for multiple users.
Sort of - I had always thought of a salt as another password - something to keep secret so that if the dbase of hashes was lost, there was an "unknown" component that would take an age of searching to find.
This logic is clearly flawed - if they have the dbase they presumably have everything.
So I now understand more clearly - salts are there to
1. pad out the plaintext to increase time to compute
2. convert plaintext from commnly used words (pass1) to
unique plaintext, reducing the ease of cracking multiple
passwords.
In short, salts help slow down the attacker when he has all your hashes. Just like bcrypt et al.
Even if you know that hash('password', 'salt1') hashes to a a user's hash, you'd need to recompute hash('password', 'salt2') to check if it's the hash for someone else. It slows them down by increasing the amount of work. If they had the same salt it would be the same hash for multiple users.