This is a chart of general-purpose hashes, not password hash constructions. All the hashes on Valerie's chart are bad password hashes.

I said nothing at all about sha1 being "the best ... you could pick". You read that in from somewhere.

I said it (sha1) was significantly better than MD5 or plaintext. That neither says nor implies that sha1 is best, just that it was better than other options that some might have chosen in 2012.

And that is false, sorry to say. Plainly false. The weaknesses unique to MD5 (in 2012) and SHA1 (in 2016) don't matter for password hash constructions. The weaknesses shared by salted MD5, SHA1, SHA2, and SHA3 --- each a distinct construction from the underlying hash --- matter hugely for password storage.

The problem is that MD5, SHA1, SHA2, and SHA3 are not password hashes. The password hash constructions in common use are PBKDF2, bcrypt, scrypt, and Argon2. Some of them use SHA2 as a primitive, some of them don't, but none of them work by simply concatenating a salt with a password and hashing.

It doesn't matter if it's a "password hash" if it's a cryptographically secure hash and a long enough password. If it can withstand all the attacks that give you shortcuts to finding out what the input was, given the output, it's fine.

Password hashes only help protect against brute force searches by increasing the cost to attack linearly with the cost to verify. But that isn't a great tradeoff and isn't future-proof.

All the crypto engineering that goes into password hashes is about the fact that passwords aren't long enough, so your "if" caveat makes your argument rather disconnected from the real world. People won't use passwords with the sufficient amount of entropy, they couldn't even if they wanted to (because of memorizing difficulties, typos, lack of good text entry UI on mobile devices, etc).

As long as you're using a password entry field designed for manual entry, you can't credibly counter that with "people should use password managers and autogenerated long line-noise passwords". Because you can't base your security upon all your users taking the initiative and doing the power-user non-default thing.

It's also true that even with a "password hash" your short password is not secure. It makes the attack more expensive, maybe from $10 to $10000 today, or $1000 next year. But practically that isn't something you should rely on.

Now you flipped over to the other extreme :) I'll leave it to others to argue how there are parameters that make an acceptable tradeoff for proof-of-work hashes like scrypt for many applications.

I didn't flip - my point is "password hashes" and other secure hashes are similarly secure. You need a long password to trust it won't be brute-forced.