Does OAuth “state” mitigate any genuinely dangerou

I was using the OAuth Playground to better understand the OpenID Connect flow, and it has this to say about verifying the state parameter:

The user was redirected back to the client, and you'll notice a few additional query parameters in the URL:

?state=7ymOWcwttpCfDNcs&code=Tav2TPBjSNvR8aowA3oe

Since it's possible for an attacker to craft a GET request that looks similar to this, an attacker could provide your application with junk authorization codes. You need to first verify that the state parameter matches this user's session so that you can be sure you initiated the request, and are only sending an authorization code that was intended for your client.

Based on this explanation, it seems that the only "attack" we are preventing with the state parameter is one in which the attacker sends our application bad codes, we check the bad code against the authorization server, and we get rejected.

But afaict this doesn't actually get the attacker much or harm us much: We're just making some extra http requests to the auth server that we wouldn't have needed to make if we'd rejected the request immediately on our server when the state didn't match.

My question is: Is my understanding correct, or am I missing a more consequential attack vector that state is preventing?

My question is: Is my understanding correct

Why ?

The OAuth 2.0 specification provide a solid example on what can be done with forged redirects. First, from the definition,

state : RECOMMENDED. An opaque value used by the client to maintain state between the request and callback.

State helps to associate authorization request with authorization response and prevent cross-site request forgery. Think that your client have a redirect URL which receive the response. What if malicious party redirect with a valid access token (when using Implicit flow) to your client. And what if this access token allow access to a valid resource belongs to malicious party in the same resource server you use. OAuth 2.0 (RFC6749) give a solid example for this on bank account details.

A CSRF attack against the client's redirection URI allows an attacker to inject its own authorization code or access token, which can result in the client using an access token associated with the attacker's protected resources rather than the victim's (e.g., save the victim's bank account information to a protected resource controlled by the attacker).

State parameter prevents this type of attacks. Furthermore, I welcome you to go through RFC6819 - Threat Model and Security Considerations. It include many attack vectors and counter measurements one could take when adopting OAuth 2.0. It include a section about CSRF attack and usage of state as well.