For authentication controls, Owasp gives advice to prevent brute-force attacks by locking out account, and I see this kind of advice in several places (blocking by source IP after failed logins, blocking by account ...).
I mean, two cases here :
either you securely store your passwords in database with costly verification (bcrypt, argon2, ...) : in this case, your passwords are supposed to resist to offline attack, when the attacker has direct read access to the database. And i think they will : if password verification takes on server side ~ 0.05s with a decent hardware and you impose a password length of 7 character AND forbid common password (included in a potentially big list), it will take on average
0.05 * 62^7 / (2*3600*24*365) = 2 800 yearsto decrypt each password (assuming users chose passwords of 7 characters in
[a-zA-Z0-7]). Unless your threat model imply attacker having a really big computing power, I find it enough. And online attack (brute-force using the login form) is slower than offline attack : is there still a need to block the attacker if its bruteforce attempts are bound to fail for quite a long time ? And yes, the brute-force attempt will be a kind of (D)DoS, but this has to be mitigated by general anti-(D)Dos techniques which are not specific to login forms.
either you do not store your password securely (fast-to-compute hashes, no salt, no hashes at all ...) : this is a problem and you should first consider securely storage of passwords. And if you can't (software legacies ...), simply adding a 200ms delay to each password verification achieves a similar protection in the login form (but not in the case of database leak / offline attack), and is far more simple to implement.
In none of these 2 alternatives I see blocking brute-force attempts a good solution. It adds complexity and potentially creates DoS vulnerabilities.