SRP is designed to protect the transmission of the password against brute-force attacks, even in case the password could be easily bruteforced.
However, if some Blizzard authentication server was compromised, the relevant attack vectors are different. Apart from the storage-scheme, the adversary can also listen in to ongoing transactions and, in parallel, store the temporary DH secrets generated by the SRP servers. The latter attack is a bit complicated and requires extensive preparation by the attackers, however, it would surely leak any logins used to authenticate to the compromised system.
The more traditional attack vector is the verification values. In SRP, the verifier values on the server side are not traditional hashes but results of an exponentiation, like in Diffie-Hellmann.
To my knowledge there is no detailed analysis of SRP vs. PBKDF2 or bcrypt. Somewhere on the SRP site (srp.stanford.edu) I once saw a note that people implemented a bruteforcer and found the required bruteforcing effort to be similar to traditional bruteforcing of hashes.
This is kind of expected: It is known that such exponentiations are hard to invert, just like a hash function. Assuming Blizzard implemented a standardized protocol like RFC2945 and did not try to invent the details on their own, these verification values will also contain a salt to make rainbow-tables impractical.
The main difference then is in the effort of bruteforcing individual verification values. Here, systems like bcrypt/PBKDF2 employ a scaling factor to increase the computational effort per password guess. The SRP schemes I know do not explicitly support this. Exponentiation is typically a bit more costly to compute than a hash, but this depends on the group (modulus) in which you're operating. I think increasing the modulus of the verification value in SRP is easily possible, but it will also increase the computation effort for 2 other exponentiations per peer that have to be done in every protocol run.
Update: Looking at RFC2945 once more, the password and salt is first hashed and then exponentiated. It would be easy to use PBKDF2 here instead of just hashing to implement a scaling factor for the bruteforcing effort without much impacting the rest of the protocol. Additionally, even when a small/unsuitable exponent N was chosen, the scheme is still as secure as a simple challenge-response-based pw-authentication.
Overall, Blizzard is probably a bit lucky as their kind of pw-storage is very uncommon and appropriate bruteforcers are not commonly available. However, for a determined attacker the SRP way of storing secrets is no more secure (possibly slightly less secure) than the state-of-the-art approach with a decent anti-bruteforce scaling factor. That being said, I applaud Blizzard for using some state-of-the-art crypto for their password-authentication, since online-bruteforcing is typically much more problematic.