Explain the concept of channelbinding.

TLS Channelbinding is targeted to prevent MitM exposure of 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 commodity nowadays. Enterprise decrypting proxies creating air gaps 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 certificates is not just trusted in general but is the one that 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 channels 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 the case of the tls-server-end-point method it is just another method of inband certificate pinning. Client directly (digest) and indirectly (hmac) passes the fingerprint of the certificate it is connected to and if the 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 preimage attack) and key theft. Compared to tls-unique where trust anchor is TLS session keying material - so even if an attacker has your cert+key server would still detect difference in TLS nonces. Net result is - neither your credentials (SCRAM-) nor your data (-PLUS) is exposed to MitM as the server refuses to accept your authentication if it detects broken integrity.