OAuth2のスコープの利点は何ですか？
質問では、
scopeをstateに置き換えます。間違った質問に基づいた回答があるので、以下はすべてそのままにしておきます。それでも答えは役に立ちます。
この質問は、OAuth2の 現在のドラフトv と GitHub's の実装について言及しています。
GitHubの「Webアプリケーションフロー」は、仕様に記載されているように、多かれ少なかれ Authorization Code Grant の実装です。クライアント（Webアプリケーション）は、GitHub上の特別なページにユーザーを誘導し、ユーザーが自分のリソースへのアプリケーションアクセスを許可するかどうかを尋ねます。これが確認されると、ユーザーはクライアントにリダイレクトされ、一時的なコードを使用してOAuthトークンを将来使用するために取得します。
クライアントがGitHubへのユーザーのリクエストにscopeパラメーターを提供した場合、リダイレクトにはそのパラメーターも含まれます。スコープがクライアントだけが知っている秘密である場合、クライアントは他の誰もその要求を作成していないことを確認できます。つまり、ユーザーがCSRF攻撃の被害を受けていないことを確認できます。
しかし、それは本当に必要ですか？
scopeパラメータを使用するためにnotを選択し、ユーザーが本当にCSRF攻撃の犠牲者である場合でも、ユーザーはそれでも受け入れなければなりません。クライアントがユーザーの情報へのアクセスを許可されているかどうかをGitHubが尋ねる質問。このステップはスキップできません。確かに仕様書によれば
[]承認サーバーは、リソース所有者を認証し、（リソース所有者に質問するか、他の方法で承認を確立することにより）承認決定を取得します。
攻撃者がクリックジャッキングのような他の手法を使用してユーザーをだましてリクエストを受け入れた場合、私はすべての賭けがとにかくオフであり、スコープはユーザーを保護しません。
結論として、スコープは実際にどのような脅威に対してユーザーを保護しますか？
状態パラメーター
Scopeパラメータは、CSRF攻撃から認証リクエストを保護するためには使用されません（下記参照）。しかし、あなたの説明と一致する「状態」と呼ばれる別のパラメータがあります。
【ユーザーへのお願い】
このステップはスキップできません。
残念ながら、この仮定は正しくありません。ユーザーが初めてクライアントアプリケーションを使用するときに、許可が求められることは非常に一般的です。その後、サーバーはクライアントアプリケーションを記憶し、アクセスを自動的に許可します。
確かに仕様書によれば
[]承認サーバーは、リソース所有者を認証し、（リソース所有者に質問するか、他の方法で承認を確立することにより）承認決定を取得します。
他の手段には、アプリケーションがサーバーによって信頼されている（同じ会社が所有しているなど）か、ユーザーの決定が保存された、などがあります。
そのため、状態パラメータがなければ、攻撃者はユーザーをだましてアプリケーションにログインさせることができます。これは、原則としてユーザーに知られているか、一般にサーバーによって信頼されています。
スコープパラメータ
スコープパラメータは、クライアントが要求する権限のリスト（-===-）を示すために使用されます。
承認エンドポイントとトークンエンドポイントにより、クライアントは「スコープ」リクエストパラメータを使用してアクセスリクエストのスコープを指定できます。
たとえば、ソーシャルネットワークの権限には次のものが含まれます。
post_to_my_wall send_notification post_to_my_friends_wall read_my_age
Scopeパラメータの値は、スペースで区切られ、大文字と小文字が区別される文字列のリストとして表されます。文字列は認可サーバーによって定義されます。
サーバーは、要求されたすべての権限または変更されたリストを提供する場合があります（たとえば、ユーザーが一部の権限を拒否したため）。
発行されたアクセストークンのスコープがクライアントによって要求されたスコープと異なる場合、認可サーバーは「スコープ」応答パラメータを含めて、実際に許可されたスコープをクライアントに通知する必要があります。
ソース： https://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.
（答えは、OPが「スコープ」ではなく「状態」について話すことを意図しているという仮定に基づいています）
「状態」パラメータはセキュリティ機能を意図したものではないと思います。これは、承認フローが完了した後に取得したいデータをコンシューマが取得するために使用できる単なるパラメータです。
これは、コンシューマが自分で状態を維持できない場合（セッションベースではなく、ステートレスクライアントなど）に役立ちます。承認フローにはユーザーのブラウザーをプロバイダーにリダイレクトすることが含まれるため、クライアントは、たとえば、ユーザーが認証フローをトリガーしたときにユーザーがいたページ（またはユーザーが実行しようとしていたこと）を追跡できなくなる可能性があります。
その情報を状態パラメータで渡すことにより、クライアントは自動化フローの後で情報を取得し、たとえばユーザーを適切な場所にリダイレクトできます。