Could it also be that by having this intermediate step prevents the client from seeing the access token?
From O’Reilly book:
Authorization code This grant type is most appropriate for server-side web applications. After the resource owner has
authorized access to their data, they are redirected back to the web
application with an authorization code as a query parameter in the
URL. This code must be exchanged for an access token by the client
application. This exchange is done server-to-server and requires
both the client_id and client_secret, preventing even the resource
owner from obtaining the access token. This grant type also allows for
long-lived access to an API by using refresh tokens.Implicit grant for browser-based client-side applications The implicit grant is the most simplistic of all flows, and is optimized
for client-side web applications running in a browser. The resource
owner grants access to the application, and a new access token is
immediately minted and passed back to the application using a #hash
fragment in the URL. The application can immediately extract the
access token from the hash fragment (using JavaScript) and make API
requests. This grant type does not require the intermediary
“authorization code,” but it also doesn’t make available refresh
tokens for long-lived access.
UPDATE – yes indeed:
When Should the Authorization Code Flow Be Used? The Authorization
Code flow should be used when
Long-lived access is required.
The OAuth client is a web application server.
Accountability for API calls is very important and the OAuth token shouldn’t be leaked to the browser, where the user may have access to
it.
More:
Perhaps most importantly—because the access token is never sent
through the browser— there is less risk that the access token will be
leaked to malicious code through browser history, referer headers,
JavaScript, and the like.