Why does the authorization code flow send a code through the browser and the tokens over a back channel, instead of simply returning the access token in the redirect?

Question

Accepted Answer

The browser is an exposed channel (URLs end up in history, logs, Referer headers, malicious extensions); only a short-lived, single-use code that is worthless without the client's credentials travels there, while the valuable tokens go directly to the client's backend over TLS.
Consider what an attacker could do with each artefact if they read the redirect URL:

An access token in the URL could be used immediately against the API: it is a bearer token.
An authorization code is useless on its own. To turn it into tokens, the attacker would need to call the token endpoint with the matching client authentication (the client secret) and the same redirect URI, within a few minutes, before the legitimate client redeems it.

So the split lets each channel do what it is good at. The front channel is needed because only the browser can show the user a login page and carry their session cookie at the authorization server. The back channel is needed because only a direct server-to-server connection is private and lets the client authenticate. The code is the bridge between them.
Tip: Front channel = visible, through the user's browser. Back channel = private, server to server. Valuables (tokens, secrets) only ever use the back channel.
Go deeper:

RFC 9700, Section 2.1: Protecting Redirect-Based Flows — the current rules for keeping codes and tokens safe in redirects.
 OpenID Connect Core 1.0: Authorization Code Flow — notes the benefit of not exposing tokens to the user agent.