man curl:

   -H/--header <header>
          (HTTP)  Extra header to use when getting a web page. You may specify
          any number of extra headers. Note that if you should  add  a  custom
          header that has the same name as one of the internal ones curl would
          use, your externally set header will be used instead of the internal
          one.  This  allows  you  to make even trickier stuff than curl would
          normally do. You should not replace internally set  headers  without
          knowing  perfectly well what you're doing. Remove an internal header
          by giving a replacement without content on the  right  side  of  the
          colon, as in: -H "Host:".

          curl  will  make sure that each header you add/replace get sent with
          the proper end of line marker, you should thus not  add  that  as  a
          part  of the header content: do not add newlines or carriage returns
          they will only mess things up for you.

          See also the -A/--user-agent and -e/--referer options.

          This option can be used multiple times to add/replace/remove  multi-
          ple headers.

Example:

curl --header "X-MyHeader: 123" www.google.com

You can see the request that curl sent by adding the -v option.

tl;dr: This is all because of security reasons.

OAuth 2.0 wanted to meet these two criteria:

1. You want to allow developers to use non-HTTPS redirect URI because not all developers have an SSL enabled server and if they do it's not always properly configured (non-self signed, trusted SSL certificates, synchronised server clock...).
2. You don't want hackers to be able to steal access/refresh tokens by intercepting requests.

Details below:

The implicit flow is only possible in a browser environment because of security reasons:

In the implicit flow the access token is passed directly as a hash fragment (not as a URL parameter). One important thing about hash fragment is that, once you follow a link containing a hash fragment, only the browser is aware of the hash fragment. Browsers will pass the hash fragment directly to the destination webpage (the redirect URI / the client's webpage). Hash fragment have the following properties:

• They are not part of the HTTP request therefore they can't be read by servers and because of that they cannot be intercepted by intermediary servers/routers (this is important).
• They only exist on the browser - client side - so the only way to read the hash fragment is using JavaScript that runs on the page.

This makes it possible to pass an Access Token directly to the client without the risk of it being intercepted by an intermediary server. This has the caveat of only being possible client side and needs javascript running client side to use the access token.

The implicit flow also has security issues that requires further logic to workaround/avoid for instance:

• An attacker could get an access token from a user on a different website/app (let's say if he is the owner of the other website/app), log the token on their website, and then pass it as a URL param on your website therefore impersonating the user on your website. To avoid this you need to check the Client ID associated with the access token (for instance for Google you can use the tokeninfo endpoint) to make sure the token was issued with your own client ID (i.e by your own app) or check the signature if you are using an IDToken (but that requires your client secret).
• If the auth request did not originate from your own property (called Session Fixation attacks), to avoid this you'll want to generate a random hash from your website, save it in a cookie and pass that same hash in the state URL param of the auth request, when the user comes back you check the state param with the cookie and it must match.

In the authorization code flow it is not possible to pass an access token directly in a URL parameter because URL parameters are part of the HTTP Request, therefore any intermediary server/routers by which your request would pass (could be hundreds) could be able to read the access token if you are not using en encrypted connection (HTTPS) allowing what's known as Man-in-the-middle attacks.

Passing the access token directly in a URL param could in theory be possible but the auth sever would have to make sure the redirect URI is using HTTPS with TLS encryption and a 'trusted' SSL certificate (typically from a Certificate Authority that is not free) to be sure that the destination server is legitimate and that the HTTP request is fully encrypted. Having all developers purchase an SSL certificate and properly configure SSL on their domain would be a huge pain and would slow adoption down tremendously. This is why an intermediary one-time-use "authorization code" is provided that only the legitimate receiver will be able to exchange (because you need the client secret) and that the code will be useless to potential hackers intercepting the requests over unencrypted transactions (because they don't know the client secret).

You could also argue that the implicit flow is less secure, there are potential attack vectors like spoofing the domain upon redirect - for example by hijacking the IP address of the client's website. This is one of the reasons why the implicit flow only grants access tokens (which are supposed to have a limited time use) and never refresh tokens (which are unlimited in time). To remedy this issue, I advise you to host your webpages on an HTTPS-enabled server whenever possible.