There is a large difference in attack surface there, though:

Passwords stored unhashed in a database fail catastrophically and irrevocably against a point-compromise attacker. Hashed passwords, validated using plaintext passwords, only leak all passwords entered since the moment of compromise.

it's not about nefarious server administrators, it's about an attacker getting in, dumping the database content, logs and whatever else they can grab. they then search those for valuable information they can sell - like email addresses, username+password combos, payment info, the likes. those are then bundled and sold on the darknet to spammers and phishers.

if the credentials are in the logs they'll harvest those to attempt logins on other sites.

Except, if you run rounds on the client and server, you now never handle plain passwords (that users might be reusing) and reversing the thing you store into something you can use against that services' API is still just as hard (if not harder because you need to do either do the total rounds on plain or the server rounds on a very long input)

Not if it's scoped to the username/domain in some way (e.g. by making the client-sent value H(password, username, domain) rather than just password or H(password)).

But that would require a canonical and secure (i.e. not (only) controlled by server-fetched code) way of client-side password preprocessing, and if you have that, you can just as well use a PAKE, modern instances of which have all of these nice properties and more.

It's not the same. If you the un-hashed password leaks it can often be used to authenticate on other websites since people reuse passwords. You can't do that if all you have is the hashed password.