TLS Channel binding is targetting to prevent MitM exposure of the both Secret (password) and Data.
SASL-SCRAM itself works in a way that it allows authentication without passing the password - password is used as shared secret to perform cryptographic operations on shared non-secret (nonce). That prevents MitM exposure of credentials however it does not prevent exposure of the Data - MitM proxy should just wait till you complete the Authentication and then it will have full access to the Data.
TLS initially was designed to prevent that (server authentication) however it relies on Trust, which is a rare commoditiy nowadays. Enterprise decrypting proxies creating airgap for content analysis is a common practice, and whatever good intentions they have - they are MitMs which are breaking confidentiality and integrity of the TLS connection. Same situation happens when trusted CA signing key leaks out to the wild.
Various technologies were invented to mitigate this, things like OCSP stapling, DANE TLS, Key Pinning - mostly relying on some sort of OOB protocol/infrastructure to verify certificate is not just trusted in general but is the one what was meant to be trusted for this particular service.
So in the essence SASL-SCRAM-*-PLUS mechanisms (which is the most common implementation of the TLS Channel Binding) is another method to achieve that - now using inband channel however, not relying on any other components.
Channel Binding enforces the trust between client and server, so that Client informs the server whom it thinks it speaks to, and Server validates whether it is correct or not. So now if you are passing via corporate MitM proxy server will reject client's authentication because the Client would pass different trust anchor details. And by trust anchor here is meant Channel Binding data.
In case of tls-server-end-point method it is just another method of inband certificate pinning. Client directly (digest) and indirectly (hmac) passes fingerprint of the certificate it is connected to and if server detects this is not matching to the certificate it actually uses it will simply reject authentication. Certificate pinning using this binding method allows you to use existing reverse-proxy/tls-offload/load-balancing mechanisms inline with channel binding but maintains existing weaknesses - static binding data (enabling pre-image attack) and key theft. Compare to tls-unique where trust anchor is TLS session keying material - so even if attacker has your cert+key server would still detect difference in TLS nonces.
Net result is - neither you credentials (SCRAM-) nor your data (-PLUS) is exposed to MitM as server refuses to accept your authentication if it detects broken integrity.