I don't know much about Bitwarden, so this is a general answer.
Taking from Steffen Ulrich's answer though, let's analyse this flow:
- User enters password in his application
- The application hashes the password
- The hash is sent to the server
- The hash is hashed again and compared to a stored hash-of-a-hash-of-a-password.
I'm omitting parts like salting and the choice of the hash algorithm, because all that they do is just make bruteforcing (aka guessing all possible passwords to find one that matches a hash) harder. We'll assume that the hashing algorithm is good enough that bruteforcing is infeasible.
So what's the reason for hashing at points (2) and (4)?
The hashing at (2) is done to remove the actual password from sight. People often do use the same password on multiple websites, so we want to do all that is possible to prevent hackers from seeing them. Even if our website gets compromised, at least we can protect our user's accounts on other websites. By hashing it already at (2) we ensure that no matter what the hackers might have compromised further down the line, they will NEVER get to see to the actual password.
Of course, if they have compromised your computer and installed a keylogger, then you're doomed. 100% security is impossible. But other parts of the system can be protected. And for hackers it is more efficient to go after servers, which are central points where 1000's of users connect to, than to try and hack 1000's of user computers (although the latter can be somewhat done with viruses and phishing).
Anyways, back to our scheme. So the point (2) is clear - but then why (4)? Precisely because of what you observed - that if someone gets their hands on the hash from (2), then even if they don't see the actual password, they can at least get access to THIS system. The hashing at (4) makes that harder, because it removes one place where the hashes from (2) could be found en masse - the database which stores them. Servers can and do get hacked, and every so often a hacker finds themselves with access to some database. Maybe it is the live production database, maybe it is a backup copy, who knows. The point is - if we do step (4), then the hashes from (2) won't be there. Only hashes-of-hashes. And you can't use those to log on to the system.
Of course, if you have access to the database, then maybe you don't care about knowing the hash from (2) anymore... Or maybe there is still something that cannot be accessed without knowing it. For example, you could encrypt some data by using the hash from (2) as a key.