Edited based on comments. I previously thought the OP was referring to redirect_uri validation during the authorization request, and linked to an example of an attack here. I've updated the answer below.
TL;DR: If a static redirect URL is required to be registered and is strictly matched by the provider, I do not believe that the redirect_uri would be required during the access token request.
The registration requirements (220.127.116.11) indicate that the redirect URI should be registered. However, not all providers perform exact matches of the redirect URI, although the spec requires it. The OAuth spec attempts multiple countermeasures to guard against these possibilities, with the redirect_uri <-> authorization code binding requirement described in the Threat Model and Security Considersations RFC (18.104.22.168).
For example, GitHub matched URL prefixes, which lead to the attack described here by Egor Homakov. In particular, Bugs 1 and 2 allowed an attacker to use a white-listed redirect URI to obtain a code, and then use that code to complete the callback flow and gain access to the victim's account. In this case, the client (Gist), sent the right redirect URI to the provider (GitHub), and GitHub would have not granted the access token if it had checked to ensure the redirect URI was the same one used during the authorization request:
It was flawed: no matter what redirect_uri the Client sent to get a token, the Provider responded with valid access_token.
The attacker could hijack the authorization code issued for a "leaky" redirect_uri, then apply the leaked code on real Client's callback to log in Victim's account.
To summarize, the redirect_uri is required when obtaining an access token to ensure that a leaked code from a redirect to a page the attacker can insert code in doesn't immediately compromise the OAuth flow. A more complete overview of the attack vector is described here by Egor as well:
The attack is straightforward: find a leaking page on the client's
domain, insert cross domain image or a link to your website, then use
this page as redirect_uri. When your victim will load crafted URL it
will send him to leaking_page?code=CODE and victim's user-agent will
expose the code in the Referrer header.
Now you can re-use leaked authorization code on the actual
redirect_uri to log in the victim account.
Remediation: flexible redirect_uri is a bad practise. But if you need
it, store redirect_uri for every code you issue and verify it on