Re pepper: It's a STRONG password. It turns '12345' into 64 random characters + '12345'. Meaning that you can't brute force against a dictionary, unless you have that pepper value. Which is only stored on the production system. This turns a well-known attack vector of "developer loses a data dump" into something that won't expose passwords.
Re hash: yeah, use a strong hash function. Never advocated otherwise.
Defense in depth is awesome, and not to be ignored. Just like we secure the database with a password, in addition to securing the server (with ssh keys), in addition to keeping software up to date, in addition to rate-limiting online password attempts, in addition to... well, you get the idea. Protect at every level. Make the attacker work as hard as possible.
Leaving identifiable bits in the hash makes it easier to do things like
if pass_type ($1$) { on_logon $upgrade_to_pass_type$6$)
> At worse, you slow them down a bit, allowing you to do things like mass-email everybody affected.
If you ever know at all.
Better to use 'not fast' hashes like bcrypt, scrypt, or PB(something) that requires far more work and far slower cracking.