SCRAM isn't ideal either
SCRAM has to send the salt and iteration count to the client, which means an extra round trip and leaking information to an attacker posing as a client. While leaking the salts isn't fatal, it'd be better if it could be avoided.
The SCRAM design could be fixed by using a One-Way Accumulator rather than an HMAC, but if you're going to do that (elegant as it is), you might as well do a bit more work and implement a Zero-Knowledge-Proof authentication mechanism. We already have TLS SRP suites, so there's no need to add SCRAM suites to TLS.
The extant SRP suites aren't ideal (no GCM ones, for example), but they're decent and adequate for most applications, and they're pretty widely supported (OpenSSL, GnuTLS, etc). Or use a strong TLS suite like ECDHE-RSA-AES256-GCM-SHA3841 and do SRP at the application-protocol (HTTP) or application layer.
(There are other ZKP protocols, such as PAK-RY, but SRP is the most widely used.)
1It's unfortunate that suite uses AES-256 rather than AES-192, since the AES key-scheduler flaw makes the former weaker and more expensive than the latter, but in practice AES with ~172 bits of effective key is still more than strong enough for most purposes.