It's only confusing because of the terms the industry uses to describe it.
To achieve the task, i.e: a GitHub being able to update an AWS Lambda without storing a secret/key/certificate you minimally need:
1. A way for GitHub to sign a request before calling AWS with it.
2. A way for AWS to verify this request was signed with GitHub.
3. A way to tell AWS what actions a valid GitHub request is authorized to do.
#1 is very easy with a public/private key signature. For #2 OIDC standardizes this part. Every IdP publishes their public keys in a standardized way. For #3 AWS already has a full permissions/roles system, so it makes sense to use that for this. Then you can get a GitHub action to do anything an AWS account can.
To string 1, 2, and 3 together you end up with the confusing flow you described.
In case of AWS, you add Github as an IDP (OIDC provider) and associate a role to it.
Github is now authenticating into AWS, scoped to the github repository where its configured and the AWS role it can assume
Its not really a typical OAuth2 or OIDC flow. And yes its better than storing the keys.
Github is not the OAuth client here.