I agree with the OP. If you think about what the lockout protects you against, there is no difference between 3 or 20 attempts (or 100, for that matter).
All you achieve with these lockouts, apart from punishing forgetful users, is to prevent a brute-force attack.
You can also user it to trigger a warning that an attack is on-going, but that isn't the primary purpose (if it were, it means you are deliberately DoSing your users just to make your own monitoring job easier. That's not a very good practice).
If someone has your password database, and can hack away at it off-line, they have unlimited tries. Your 20 guesses limit is no good there.
If someone is attempting an on-line brute-force, all you need is a password that can withstand for "long enough": long enough for your IRT to respond, or long enough for your attacker to give up.
The Conficker password database is slightly below 200 passwords, IIRC, and it is filled with some of the dumbest passwords on the planet. Now let's assume that your password is not on this list. If you allow 20 password tries, say per 15 minutes, without locking, it will take an attacker more than two hours just to get through that list.
In fact, even if you narrow your guessing list down to passwords made from relevant info about that user, like kidsname02, birthday99 etc, you will still end up with at least a few tens of passwords, extending a dictionary attack to maybe an hour or more.
That constant, erroneous guessing over time is what should trigger your alarms, not a handful of wrong passwords in a couple of minutes.
So, if you can keep your users away from the most basic password pitfalls, you can happily accept a lot of erroneous password attempts.
Personally, I draw the line at 15. Totally arbitrary, and mostly a practical thing: I find that any real user has given up long before this. Usually if there's that many attempts, it's a process or session that's hanging somewhere with old credentials. And if that's not the case, then we can talk about looking for attacks.