The mathematical strengths of bcrypt vs SHA-2 are totally irrelevant.
SHA-512 is plenty big enough to require age-of-the-universe-scale CPU-effort to crack. For what it was designed for. But it simply wasn't designed for storing short bits of text like passwords. Anyone using it for that is using it wrongly, and has built a system that is far, far more prone to cracking than the theoretical strength of SHA-512 suggests.
Once you go beyond even basically competent crypto, the only thing that matters is how fast you can try likely passwords.
For passwords, SHA-512 is no better than MD5, because though MD5 has theoretical issues, no sane person will ever do a math attack on MD5 to crack your password, when they can just try all combinations of likely passwords in a few seconds or minutes.
And SHA-512 is no better than MD5 if I can try passwords at the same rate. Because I'm going to guess your password in the same amount of time. Even if you had a SHA-65536. The only practical reason SHA-512 is better for passwords than MD5 is that it takes a good chunk longer to calculate (but not long enough!).
So it is the rate of hashing, not the 'power' of the algorithm you need to worry about. And that is why bcrypt is what you should use. It isn't that it is stronger crypto, strength is irrelevant: it is slower crypto. And that's what you need when you're handling passwords.
As for 'we have a secure db and rate limited login' - why not use plaintext passwords then? SHA based hashing is only a few days CPU more secure than plaintext for short passwords. In both cases you're banking on nobody having access to the database. If you can guarantee nobody has access to the database, and you're rate limiting your logins, then why not use plaintext? No. You use password hashing explicitly because you can't guarantee db security. So use the right tool for the job.
tl;dr - Use bcrypt, it is many orders of magnitude more secure than SHA-2-based approaches.