This means that the submitted hash is effectively a password. You get a minor benefit in that it obscures the original password in case it contains sensitive info or is reused. But the DB is now storing the hash password in plain text. This means that if the DB leaks anyone can just log in by sending the hash.

If you want to do something like this you would need some sort of challenge to prevent replay attacks.

This scheme would also benefit from some salt. Although the included username does act as a form of weak salt.

Per your edit, the DB being "encrypted properly" just means "hashing server side". There's little benefit (though not necessarily zero) to encrypting the entire database, since the key has to live in plaintext somewhere on the same system. It's also making the slowest part of most systems even slower.