いろいろな需要があるからいろいろな文字集合とその符号化方式があるのです。べつに昔との互換性だけが存在理由ではありません (もしそうならどうして 2004 年になって JIS X 0213 の改訂なんかしているのか)。

ITpro の記事では、日本語文字列を扱うための符号化方式として、

• Shift_JIS (シフト JIS の JIS X 0208 版) は 1 文字 2 バイト以内でデータ長は短いけれど JIS X 0208 にある文字しか表せないから不満
• UTF-8/16/32 は新しい文字も表せるけれど、データ長が 1 文字 2 バイト以内にならないことがあるから不満

という比較をして、

日本語文字列を扱うのに，何か良いエンコーディングはないだろうか。

と問題を提起して終わっているのですが……その条件なら、 Shift_JIS-2004 (シフト JIS の JIS X 0213 版) でよいと思います。 JIS X 0213 の文字が全部使えて、しかも 1 文字 2 バイト以内です。 (ただし、当然ながら 1 文字 2 バイト以内を堅持しようと思ったら今後文字を増やす場所があまりありません。)

ITpro の記事の著者が存在を知らないだけ? JIS の規格票にも書かれている符号化方式なのですが。僕が何か勘違いをしている? (その可能性は高いです。)

僕は 1 文字 2 バイト以内であることが重要になるようなギリギリの世界でプログラムを書く予定はないので、日本語以外も扱える UTF-8 や UTF-16 で十分です (UTF-16 は Windows のネイティブの符号化方式なので使います。それがなければ UTF-8 だけで十分)。でも、僕の需要だけ満たしてくれても駄目で、世の中にはいろいろな需要があるので、すべてが UTF-8 になるわけがありません。日本語の文字だけ表せればよくて、その代わり UTF-8 や UTF-16 では駄目なくらいデータ長に厳しい制約が課せられる状況では、 Shift_JIS-2004 が適任だし、そんな状況はありえなくはないでしょう (珍しいとは思いますが)。

Unicodeが流行る背景にはソフト開発のグローバル化がありますよね。
英語版を作って日本語版にローカライズするのではなく、最初から内部処理はUnicode（UCS-2）で作って、UIのみ各国語で作る。以前、あるメールアプライアンス会社の人が「うちの製品はUnicode対応なので日本語にも対応している」と主張するアメリカのエンジニアに「日本ではISO-2022-JPという特殊なコードが使われている」ことを説明するのに難儀したと言っていました。簡単にいえば、インドでアプリを作って世界中に売りまくるビジネスが流行っているので、このままUnicodeで行くんじゃないですかね。

もちろん、Unicode（UCS-2）あるいはその符号化方式としてのUTF-8やらUTF-7、書体への対応付けにはいろんな問題もあるんでしょう。しかし、「文字の話は7層に分けて考えてねー」 [ietf.org]って言っている人たちもいますよ。問題があれば符号化層ではなくて、上位層のタグ付けなどで解決するのがスジなんじゃないでしょうか。