The author makes a number of good points. In fail2ban's defense, it can be used for a lot more than just blocking IP addresses based on SSH failures. At one p

The author makes a number of good points. In fail2ban's defense, it can be used for a lot more than just blocking IP addresses based on SSH failures. At one point in the past I adapted an existing fail2ban setup to ban IP addresses that were running malicious vulnerability scans against a large legacy PHP webapp, using some dumb heuristics that worked and were easy to put in place. Would it have stopped sufficiently motivated expert attackers? Of course not. Did it reduce the load on the legacy PHP app and improve the signal to noise ratio in our webserver logs, while reducing the chance a brute-force attacker would find some hole lurking in a long-forgotten corner of the app's unfortunately-large attack surface? Yup. So, I'd argue it can be useful, even if naive SSH blocking may not offer much improvement.