Though I would add that looking back to when I was an IC, my Computer Science degree hadn't given me much if any formal training in Software Engineering (especially in a large team and code base) and I mostly learnt by doing that also.
If someone is performing a denial of service attack from one I.P. address then this will help.
To tptacek's point, you've got to ask yourself is a denial of service attack in your threat model?
The reality is most folk set up fail2ban after seeing auth failures in their logs, not service degradation.
If you're considering a denial of service attack in your threat model, then I'd probably also consider a DDoS attack and there are likely more effective solutions here (a firewall or CDN).
And don't forget you're using some of those precious CPU cycles to parse the auth logs, with python no less :-)
fail2ban is a real pet peeve of mine because anyone security conscious enough to deploy this will have likely already mitigated any actual security risks this could help with either by using a strong password or public key authentication.
That leaves noise in the logs - which sure, it's nice to reduce, but using an alternative port can help here.
I may sound like a spoilsport - but the fact that there have been a number of security vulnerabilities (https://www.cvedetails.com/vulnerability-list/vendor_id-5567...) in this project, make it worse than security theatre, it actually increases risk whilst not at all reducing it.