Why does a verifier store a salted hash of a password as the credential instead of the password itself?

So that a stolen credential database does not reveal the passwords: the verifier only needs to recompute the hash of the submitted password and compare, and salting plus a slow hashing scheme makes offline guessing expensive.

* The verifier can check a password without ever storing it. *

Why each ingredient matters:

• Hash, not plain text or reversible encryption: a hash is one-way, so the database alone does not give the password back.
• Salt: a random value (at least 32 bits per NIST) stored with each hash. Two users with the same password get different hashes, and precomputed tables (rainbow tables) become useless, because the attacker must attack each hash separately.
• Slow password-hashing scheme with a cost factor (Argon2id, scrypt, bcrypt, PBKDF2): a deliberately expensive function, so an attacker can test far fewer guesses per second than with a fast hash like SHA-256.
• Optional pepper: an extra keyed hash with a secret key kept separately, ideally in a hardware security module, so a stolen database is useless without that key.

Hashing does not help against weak passwords: a cracker still tries 123456 first. It buys time and makes strong passwords effectively uncrackable.

Go deeper:

• OWASP Password Storage Cheat Sheet — recommended algorithms and parameters, salting and peppering.
• How NOT to Store Passwords! (Computerphile, YouTube) — from plain text to salted slow hashes, step by step.
• Salt (cryptography) (Wikipedia) — what a salt defends against and what it does not.