Blocking Brute Force attacks by implementing password lockout is a good idea in general. A lot of people think they might have good passwords until they've seen a brute force tool (such as John the Ripper or L0pthcrack) in action (these are working on password files, not across the web as you are describing) but the length of time to crack even seemingly difficult passwords is laughably short. I'm not sure how many attempts they need to crack the password, but given the length of time, it probably isn't very many.

Something to consider is what you are trying to protect. If it really doesn't matter if the information gets out - it can't be used against someone for example - then perhaps it really doesn't matter. But if you are storing personal information (phone numbers, addresses, etc.) then you might want to implement additional levels of security. Basically, make it not worth someone's while to try to break in and steal it. A simple threat analysis should give you a good indication of what you might want to consider doing.

If you work someplace where the risks and potential damages are high if information is stolen or compromised, then you want to take every possible step to make that information safe. The flip-side of course is making the site easy to use. Security is a balancing act between Ease-of-use and Security.

In response to your comment <cite>What kind of web server will actually allow a IP to "keep calling the script..."</cite>, it depends on how it's configured. I've seen logs after a brute force attack on a site and its not pretty. Even with lockouts in place. Unless the site can be configured to block brute force/DOS attacks, your app will continue to get hit until the attackers gets bored, or all available bandwidth is soaked up. I can only speak to IIS but from what I saw, there really is no way with the server to do this. We've installed another server that does allow us to block sites after X number of attempts (its looking to limit possible DOS attacks). In addition, we have firewall restrictions in place that keep J. Random Script-Kiddie from getting through easily. But also, I work in a place where we take security very seriously in part because its in the best interest of our customers and the fines for failing to adequetly protect customer info can be very very steep (including hefty fines and possible jail time as well).

If you're looking at some sort of bulletin board, do you want to be able to provide some accountability and make sure that the person posting is the person who registered? Password locking is simple to implement but if the password is comprimised - what are the consequences for you and for the person whose password is compromised.

Enoguh rambling for now - I'm looking forward to reading the rest of the comments here to see what people thing :-)