It might get individual attackers but entire botnets? No.
I've seen co-ordinated attacks from botnets where hundreds of separate and geographically-disparate systems will coordinate on the same username list to brute force the password.
For my systems, SSH is administrative use only, so it got put behind port-knocking. Mail collection from that machine is administrative only, so it got put behind port-knocking. Users who need it can be bundled with a port-knocking utility that runs on logon quite easily.
I'm not suggesting it for mass-email servers, but those should be managed properly anyway. However, for all those other servers that are offering SSH for administrative purposes, hiding them behind either a different port number or port knocking cuts out brute-force attempts immediately.
Your solution relies a single attacker only ever coming from a single IP. Even with your rate-limiting, a botnet of anywhere near decent size could still perform several million attempts a day just by handing off portions of a brute force task to a few thousands of its machines. And the chances of you picking up on it are even less, and the chances of blocking it (without affecting legitimate users) are near-zero.
I'm fast moving all external provided services to be behind the VPN for known users. There are few devices these days that can't handle VPN'ing in to get a job done. For public-facing services (website HTTP, SMTP) rate-limiting is all you have and only keeps the most stupid of brute-forcing idiots away. However, for my use (where my personal server is only logged into by me, but potentially from multiple locations unknown beforehand) I find port-knocking the middle-ground that stops all brute-forcing while allowing me - with one extra click - to get everything I need access to. At work, anything critical is behind the VPN and the VPN is certificate-managed and rate-limited.