OAuth 2 の暗黙的な許可認可タイプの目的は何ですか? 質問する

私に盲点があるだけなのか、それとも何か他の理由があるのか​​はわかりませんが、OAuth 2 仕様を何度も読み、メーリング リスト アーカイブを精査しましたが、アクセス トークンを取得するための暗黙の許可フローが開発された理由について、まだ適切な説明が見つかりません。認可コード許可と比較すると、特に説得力のある理由もなく、クライアント認証を放棄しているように見えます。これはどのようにして「スクリプト言語を使用してブラウザーに実装されたクライアント向けに最適化されている」(仕様を引用) のでしょうか。

どちらのフローも最初は同じです（出典：https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-22):

1. クライアントは、リソース所有者のユーザーエージェントを認可エンドポイントに誘導することでフローを開始します。
2. 認可サーバーは、リソース所有者を (ユーザーエージェント経由で) 認証し、リソース所有者がクライアントのアクセス要求を許可するか拒否するかを決定します。
3. リソース所有者がアクセスを許可すると仮定すると、認可サーバーは、以前に（リクエスト内またはクライアント登録時に）提供されたリダイレクト URI を使用して、ユーザーエージェントをクライアントにリダイレクトします。

• リダイレクトURIに認証コードが含まれる（認証コードフロー）
• リダイレクト URI には URI フラグメントにアクセス トークンが含まれます (暗黙的なフロー)

ここでフローが分岐します。どちらの場合も、この時点でのリダイレクト URI は、クライアントによってホストされているエンドポイントになります。

• 認証コード フローでは、ユーザー エージェントが URI 内の認証コードを使用してエンドポイントに到達すると、そのエンドポイントのコードが認証コードとクライアント資格情報をアクセス トークンと交換し、必要に応じてそのトークンを使用できます。たとえば、ページ上のスクリプトがアクセスできる Web ページにそのトークンを書き込むことができます。
• 暗黙的フローは、このクライアント認証手順を完全にスキップし、クライアント スクリプトを含む Web ページを読み込むだけです。ここでは、アクセス トークンがあまり渡されないようにする URL フラグメントに関する巧妙なトリックがありますが、最終結果は基本的に同じです。つまり、クライアントがホストするサイトは、アクセス トークンを取得できるスクリプトを含むページを提供します。
  

そこで私の質問は、クライアント認証手順をスキップすることで何が得られるのかということです。