The problem with fail2ban is that you have another possible vulnerable program that an external user can feed information to (although very restricted).
I have always been surprised that fail2ban is so popular, since iptables can do rate limiting, etc. So, it's easy to block most attacks with the in-kernel firewall:
My understanding of fail2ban is that it watches logs and then creates iptables rules to reject IPs, not dropping them itself. Since it blocks after a number of attempts it does a rate limiting of sorts, and automates the process. I agree that using the firewall without an intermediary is more powerful and linux admins should know how to use it.
I know perfectly well what it does, and it does not change my point: extra parsing is extra scope for vulnerabilities. You also don't address my main point: you can use iptables rate limiting to block brute force SSH attempts. I used this for years and it works perfectly fine. Connecting to often within a certain timespan and you get DROP'ed.
But you probably thought that I was suggesting to block IPs by hand. I wasn't.
No, fail2ban watches logs for repeatedly failed login attempts, and then blackholes given IPs using firewall rules. I prefer denyhosts, which is more ssh-specific.