Properly implemented, SRP does not store the the secret on the server end. It only stores v=pow(g,x) mod N, where "x" is a secret needed on the client end (derived from the password), and can't be extracted from v without either using a brute-force algorithm (try all weak passwords), or solving the discrete logarithm problem. You may want to read https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol more carefully.
I hadn't looked at SCRAM before, but from at a quick glance it looks like the only thing preventing an attacker from brute forcing weak passwords from nothing but a passively captured login session is an expensive-to-compute hash function (PBKDF2). It isn't as bad if SCRAM is wrapped in an SSL/TLS session with associated certificate, but if you really trust nothing has MITMed (i.e. incorrectly trusted certificate) or otherwise broken TLS (from the perspective of the client authenticating the server), then why not just send the password directly through the tunnel (from client to server), and avoid extra complexity?
Note that capturing a login session is generally a much lower bar than obtaining the password database, and SRP does not allow brute forcing even trivially weak passwords from just a captured login exchange. (As long as there aren't any huge breakthroughs in quantum computing or other discrete logarithm algorithms.)
All that said, you are correct that SRP or other low level single-connection authentication mechanisms do nothing for the cross-party authentication issue discussed in the article.