The point of hashing a password when storing it in the DB is that it will not be disclosed if anyone got a dump of the DB.
There has to be a 1:1 relationship between the password and the hash here as you need to be able to compute the hash of a given password and verify its correctness against the value stored in the DB, something you will not be able to do if there might have been more than one correct result for hashing a password.
Using salts will not make any real difference, as any salt you will add will be constant and added in the same way and there will still be a 1:1 relationship between the password and the value stored in the DB.
The other factor that is actually highlighted when looking at how verify_password works, is that hashes many times contain signature which indicates what type of hash was used to generate them so the software can be able to use the correct hashing when comparing the values. A not careful manipulation of that value is risking that you will not be able to know which hash to use.
Last and not least is the fact that salts are configurable by the user (in wp-config.php) and if you will use a salt when hashing a password, you risk users not being able to ever login again without resetting their passwords, if a salt changes. OTOH if you hardcoded the value in the code, than since it is open source everybody can know the salt which is being used which will make the whole thing pointless.
People that feel like the way wordpress handles hashing is not secure enough for their requirement can always implement their own algorithms and override the wordpress ones.