回答:
PHPは言語として間違いなく使用できますが、問題は既存のプログラムとの互換性にあると思います。Unicodeサポートはそれらを微妙な方法で破壊する可能性があり、これは最も厄介なバグです。
現在、PHPのほとんどの文字列処理関数は「バイナリセーフ」です。つまり、これらの関数を使用して、任意のエンコーディングの任意のファイルおよび画像データなどのバイナリ形式を処理できます。
Unicode文字列を追加する場合、Unicode文字列とバイナリ文字列を混在させないように非常に注意する必要があります（文字列が異なるソースから来ており、以前に心配する必要がなかった場合は非常に困難です）。そして、あなたはもうエンコーディングについて無知ではありえませんでした（そして、多くのスクリプトはこれについて無知です！）
別の難しいが解決可能な問題は、Unicode文字列でのランダムアクセスです。$string[$offset]些細なものから非常に遅い、または少し遅く非常に複雑なものへの変更の実装。
また、PHPの内部エンコードとしてUTF-16を選択するのは間違いだったと思います。UTF-8（サロゲートペアによる可変幅）と同じ問題と、UCS-2の非効率性があります。たぶん彼らはそれを捨てて、UTF-8でやり直すべきでしょうか？
</speculation>
TLDR：多くのPHPライブラリは、Unicodeをサポートしていないか、相互に互換性のない方法でサポートしているネイティブCライブラリの単なる薄層です。この状況を修正すると、後方互換性のない変更が導入される可能性があります。
免責事項：数年前にPHPからPythonに切り替えたので（振り返ることはありません）、私の意見は明らかに偏っています。
PHPはすてきで巧妙なハックだと思います。ハックとして、それは気取らずに始まり、（コンピューター言語理論の観点から）よく考えられ統一された設計を欠いている多数の疎ライブラリーから幾分無秩序に成長しました。
マキャヴェッリが言ったように、「最初に基礎を築いたことがない人は、その後基礎を築く能力が高いかもしれませんが、建築家に問題を抱え、建物に危険をもたらすでしょう」。
プログラミング言語の場合、人気が高いほど、変更が難しくなります。そのため、Cのような言語は10年ごとに変更されます。たとえば、Python 3は後方互換性のない多くの変更を行っており、見栄えがよくありませんでした。以前のPythonインカネーションでのUnicodeサポートは、PHPの現在の状況よりも優れていると既に考えられていました。Armin Ronacherからのこの暴言は、Pythonコミュニティの大部分の不満を要約しています。
PHPは「ユビキタスな」Webプラットフォームであるため、自身の成功の犠牲になります。PHPでユニコードを統一的にサポートすることは避けられませんが、大量の血、汗、涙が必要になります。
古いPHP 6の作業が停止された主な理由の1つは、内部の複雑さと実行する作業量のためでした。
ちょっとした歴史：PHP 6のUnicode実装は、より大きなPHPユーザーのニーズによって設計され、Unicodeを「正しく」実行しようとしました。いくつかの評価の後、PHPのUnicode対応の主な設計者は、内部でUtf-16である新しい文字列タイプを追加し、さまざまな場所でさまざまなエンコーディングを使用できるようにしました。そのため、コードは1つのエンコードで記述され、出力は別のエンコードを使用し、他のエンコードを「runtme操作」する可能性があります。UTF-16を選択する理由は、UTF-16を使用するICUライブラリに基づいて作業を行う必要があり、utf-とutf-16の間の変換は比較的安価でありながら、このエンコードは一般的な文字列操作を高速で行うことがわかったためです。ここまでは順調ですね。
これを行うことの結果は、何よりも新しい文字列型の導入です。それまでのPHPの内部型システムにはいくつかの型（NULL、bool、int / long、float / double、文字列、配列、リソース、オブジェクト）があり、多くのコードにはこれが当てはまるという仮定がありました。このような仮定に加えて、文字列で動作するすべての関数、およびそれらの多くは、個別に評価する必要があり、エンコードの処理方法を決定する必要があります。彼らはバイナリ文字列またはユニコード文字列で動作する必要がありますか？変換が必要な場合、どのエンコードを使用する必要があるかなど。これは多くの作業であり、場合によっては正しく行うのは非常に複雑です。さらに、内部APIは非常に複雑になりました。PHPのほとんどの主要なAPIにはバイナリ文字列（古い文字列）のバージョンがあり、多くの場合「ランタイムエンコード」文字列のバージョンがあったため、
その過程で、多くの開発者は複雑さにつまずき、utf-16に悩まされ、メモリ使用量が2倍以上になり、既存のほとんどのアプリケーションを壊しながら文字列の変換に多くの時間を費やすという事実を嫌いました。そのため、PHPはボランティアによって動かされ、開発者の数は減り、他のことも山積みになり、貢献者は不満になり、結局放棄されなければなりませんでした。
今、未来は何をもたらすでしょうか？-utf-8を中心に構築されたPHP aeでますます多くのものが発生している遅い進化があります。カスタムタイプでは強力な方法ではなく、すべてを強制します。現在、開発者はこのホットアイアンに触れる意欲はありません。誰かがそれをうまく機能させるための良い提案を持っていることを望むことができますが、現在、「みんな」は言葉を聞くだけで逃げ出します。:)
実際の理由は、PHP開発チームがPHP開発の明確なロードマップを欠いているためだと思います（php-internalsの誰かが、5.4の機能を事前に同意せずにPHP 5.4ブランチを開始することを決めたときの議論は非常に熱烈です）。私はこの言語がとても好きですが、その開発方法は少し心配しています。