What is the risk of an attacker inserting new password hashes?

In particular, I'm thinking of the attacker either generating a new hash for a known password --or taking the attacker's own hashed password-- and substituting it into another user's record."

So, the attacker's own password thing is unlikely. There are technical defences that could stop it, such as deterministic "salt" (instead of hashing just the password, hash something like the username and password together) However, the bigger reason that isn't likely is that it leaves a big red arrow pointing towards the attacker's identity!

Unfortunately, that doesn't mean that the adding a known hash thing is unlikely. You are correct that it is possible. It is something many young developers do by hand when home rolling an authentication system and not yet having the password reset form working. It is also fundamentally how password reset forms work: just overwrite the hash you don't know with one you do.

Essentially, if an attacker has write access to the users table, hashing does not protect it. You might get a small level of defence if you include "pepper" in the hash (which is just a secret value stored away from the database) but with this level of access there is just unavoidably a lot of scope for harm. Other options for attack include changing the type of a user to a privileged one, or messing with the table to prevent real users from logging in, in a DOS attack. Pepper in the hash doesn't help against those.

The take home is yes, hash passwords because it prevents a specific sort of harm (namely password harvesting) but that should not be the only area of security. You also need best practices such as separation of privilege to avoid an attacker having write access to a database to begin with.