You don't lockout the account, you lockout the attacking client, typically by IP address. It still allows the attacked accounts access from non-attacking IP addresses.
I would think that if you have an attacker on the intside of your corporate network trying to brute force accounts on an external service, you have wayyy more problems than locking out everyone else from the corporate network.
And I still don't care if everyone else on your network can't access my service; until you find the hacker and put a stop to it, why should I have any trust in your network address? The street goes both ways here.
It seems like the three main strategies are locking the account, blocking the IP, or forcing a password reset. What if instead, the account login name automatically got changed after a few missed attempts but the password remained the same. That would get around the DoS problem and also the corporate IP / AOL problem.
I think rate limiting is a better option. If you only allow one log in attempt per X seconds, it becomes much harder to do a dictionary attack in a reasonable amount of time.
This to me is the way to do it. You can limit it to something pretty large like even or 3 tries, wait ten seconds or something. Basically making it normal speed for a human but waaay slow for a computer is the trick to me. A dictionary attack has to try tens of thousands of words and combinations to crack an account.