I understand that the token exchange flow in OAuth2 is an addition to the traditional OA2 description that enables resource servers accessing downstream resources on behalf of the clients. The definition for "delegation" is as follows:
Delegation semantics are different than impersonation semantics, though the two are closely related. With delegation semantics, principal A still has its own identity separate from B, and it is explicitly understood that while B may have delegated some of its rights to A, any actions taken are being taken by A representing B. In a sense, A is an agent for B.
I'm struggling to understand: is this in any way different than the client credentials traditional flow? (besides semantic differences)
The client credentials (or other forms of client authentication) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server. Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server.
From my understanding, both delegation under token exchange and client credentials allow for accessing resources from a downstream server as the resource server (server), not as a client.
USER FLOWS
The key difference is that token exchange is mostly used by resource servers in the context of a user based operation. The user has previously authenticated and consented, to create a delegation.
In many microservice setups, the RS may need to call an upstream RS. It is common to forward the original token, so that the upstream RS also checks for its own required scopes and claims. User IDs are sent securely in the access token, as opposed to in URL path segments, or headers, which would not be a secure design.
One of the main use cases for token exchange is to flow the user identity with restricted privileges. This can be done by using the original access token to get a new access token for the same user. This can have reduced scopes or claims, or a shorter lifetime.
MACHINE FLOWS
The client credentials flow is used for machine initiated flows, when no user is involved. One example might be a scheduled job. Another might be a B2B scenario, where a resource server downloads data from a business partner's resource server.
Token exchange could potentially be used here, but in most use cases would not add any new capabilities to the client credentials flow, as you indicate.