If you're using per-user salting (and you should be) then you have to do n hash calculations, not just one calculation and n comparisons.
Might be feasible for a small number of users on an internal app, but unlikely to work on a big or public site.
I'd also be worried about information leakage. If you tell me that I can't use my password then I now know that it's used by someone else. If I work out who that is (which could be quite easy) then I can impersonate them.
Even more performance-intensive than I thought - possibly why it's not been implemented.
Assuming you know that a given password can be used 10 times and there's a database of 100,000 users in your scenario above, how would you work out who that is?
Might be feasible for a small number of users on an internal app, but unlikely to work on a big or public site.
I'd also be worried about information leakage. If you tell me that I can't use my password then I now know that it's used by someone else. If I work out who that is (which could be quite easy) then I can impersonate them.