A nit: even compared to some recent designs, SRP is pretty thoughtful about offline password cracking. It's not as expensive to crack as a real password hash, but far more expensive than other PAKEs.
I haven't read enough about the other PAKEs to know what offline attacks look like there, but the fact that they are endemic to PAKEs is a total footgun.
For example, one implementation of SRP I looked at used 8-digit codes (e.g. 12345678) to connect new devices to a network. Eight digits was enough to prevent brute-forcing by repeatedly sending codes to the server, but not enough to prevent an attacker from MITMing the connection and brute-forcing the code offline, because the server was using a bad RNG.
Wait, what's the brute-force attack you're contemplating here? I'm thinking of the attack where you've compromised the servers and stolen the verifiers.
Looking back at my notes, I think my earlier comment was misleading. The offline brute force was due to an insecure random number generator, which allowed an attack against B to recover b (and from there crack the 8 digit code). So, uh, ... I'm wrong on the internet. I think we've talked about this attack before actually :P
SRP completely prevents passive MITM attacks and requires online active attack (real time impersonation of either or both parties during the handshake), and even then you can't do anything if the real server and client impose their own rate limiting
For example, one implementation of SRP I looked at used 8-digit codes (e.g. 12345678) to connect new devices to a network. Eight digits was enough to prevent brute-forcing by repeatedly sending codes to the server, but not enough to prevent an attacker from MITMing the connection and brute-forcing the code offline, because the server was using a bad RNG.