NSURLConnectionを多用するSDKを作成しています。これらすべての接続を管理するには（たとえば、それらを一括キャンセルするために）、すべてが単一のスレッド（できればメインスレッド）で実行されるのが最善です。NSURLConnectionの非同期性により、これはひどい考えではありません。スタンドアロンアプリケーションでは、すべての接続がメインスレッドで実行され、接続後にセカンダリスレッドで（実際にはGCDまたは操作キューを使用して）負荷が高くなります。結果が得られ、何も停止しません。
したがって、問題は、ユーザーが複数のスレッドとメインスレッドではないスレッドで接続を実行したい場合はどうなるでしょうか。
編集：私は自分自身を適切に説明しなかったと思います。NSURLConnectionは、同期ではなく非同期で使用しています。これにより、UIをブロックすることなく、メインスレッドですべての接続を実行できます。問題は、SDKのユーザーがこれらの接続を非同期と別のスレッドの両方で実行したいのはいつかということです。
大量のデータをロードするリクエストがあり、それが遅くなることが確実であり、頻繁にレンダリングする必要があるGUIがある場合。
この場合、GUI（Cocoaのように、GUIはメインスレッドで更新されます）がメインスレッドで更新される場合、要求が遅すぎると、更新されていないため、すべてのビューの表示が停止する可能性があります。
また、Appleのドキュメントには、sendSynchronousRequest：returningResponse：error：について記載されています。
重要：この呼び出しは失敗するまでに数分かかる可能性があるため（特にiOSでセルラーネットワークを使用している場合）、GUIアプリケーションのメインスレッドからこの関数を呼び出さないでください。
別のスレッドで非同期NSURLConnectionを実行するために私が想像できる唯一の理由は、デリゲートメソッド自体が非常に時間のかかるものである場合です。それでも、メインスレッドで実行し、処理をバックグラウンドキューに移動する可能性があります。
編集：今日、「処理をバックグラウンドスレッドに移動する」ことは非常に簡単であることに注意してください。GCDの前は、これは少し難しいので、その場合、セカンダリスレッドでNSURLConnection自体を実行する方が便利でした。また、メインスレッドで実行ループを処理しないC ++アプリにNSURLConnectionを埋め込む場合にも多少役立ちます（これは基本的にMacアプリにのみ適用されます）。
ご理解いただけると思いますが、NSURLConnectionは、内部で使用するために独自のバックグラウンドスレッドをすでに管理しています。
要するに、これに関するあなたの直感は正しいと思います。答えは「ほとんどない」です。NSURLConnectionは、メインスレッドで最も簡単に管理できます。