そりゃあ、UTF-8一択だろ。と少なくとも5年くらい前から思ってます。

使う場所としてはWebアプリ等のプログラムソース、永続化データ、クライアントに送出するファイル（html, css, js等）を想定して書きます。

日本語を表現する場合、一般的にはShift_JIS、EUC-JP、UTF-8の3つの選択肢が考えられます。
どれもメリットもあればデメリットもありますが、偉大な先人たちが作ったライブラリでエンコード・デコードをやってる身（文字コード実装の詳細に踏み込まない立場）としてはそれぞれこんな感じかなと思います。

Shift_JIS

・メリット

1. 消費バイト数が比較的少ない。
2. 国内に限れば、だいたいどのガラケーでも読める。

・デメリット

1. 亜種が多いので使いようによっては微妙に文字化けする。
2. エンコードデータに制御文字を含む場合が多いので、それを想定してない環境（外国人が作ったプログラムなど）では誤作動したり文字化けしたりする。（いわゆるだめ文字問題）
3. 文字種は少なくとも9000ぐらい（ASCII + JIS X 0201 + JIS X 0208 + α？）。亜種によりけり。

EUC-JP

・メリット

1. 消費バイト数が比較的少ない。（Shift_JISよりは多くなる場合がある。）
2. だめ文字問題がない。

・デメリット

1. Shift_JISほどではないがやはり亜種問題がある。
2. Windows, Macではブラウザで表示するだけならあまり問題はないが、デフォルトのテキストエディタが対応してないなどクライアント側での扱いに難があるかも。（TextEdit.appはきちんとメタデータがついてたら読めるらしいが。）
3. 国内のガラケーはほぼ対応してないと考えて良いかと。ゲートウェイで変換してくれる場合もあるらしいですが。
4. 文字種は少なくとも13000文字ぐらい（ASCII + JIS X 0201 + JIS X 0208 + JIS X 0212）。

※文字種の範囲が微妙に違うためShift_JISとEUC-JPの間で完全な相互変換はできない。さらに亜種問題もあってワケワカメ。

UTF-8

・メリット

1. 文字範囲がめっちゃ広い。概念的にはどの国の文字も文字化けしない。利用してるフォントにその文字が入ってなければ化けるけど。
2. だめ文字問題がない。
3. バイト列として検索しても文字の途中にヒットする事がない。
4. 亜種問題がない。UTF-16とかUTF-32は出自を考えると亜種と呼べなくもないがエンコードされたデータは似ても似つかないものになるため（というか全く違うエンコードなので）混同することがない。
5. 最近なら（といってもここ10年くらいなら）だいたいどんなPC環境でもデフォルトで読める。

・デメリット

1. EUC-JPよりはマシですが国内のガラケーは対応してない場合が多い。ゲートウェイで変換してくれる場合もあるらしいですが。
2. 日本語は一文字につき3バイト使うので容量がShift_JIS、EUC-JPの場合の約1.5倍になる。（といってもhtml, css, js, プログラムソース等はASCII文字を多く含む為、全体ではそこまで増大しない。）
3. エンコードデータの扱いに、Shift_JIS、EUC-JPと比べて計算機リソースを食うかも。
4. 冗長なコードの問題がある。しかしそういうのはライブラリ側で正常なコードに自動的に置換したり例外を出したりするようになってるはず。

とまぁ、どれも表面上は一長一短に見えます。
が、実際はShift_JIS、EUC-JPのデメリットが問題を引き起こす（またはそういった話を聞く）ことはあっても、UTF-8のデメリットが問題になることはほとんど無いですし、
UTF-8のメリットで助かった〜と思うことはあっても、Shift_JIS、EUC-JPのメリットでそう思うことはほとんど無いです。

ガラケー向けのWebアプリを作るにしても、全体的にUTF-8を使って最終的にデータを送出するところでShift_JISに変換して（そしてキャッシュして）ってな作りにしてます。

なんでこういうエントリ書いたのか自分でもよく分かりませんが、そういうことで僕はUTF-8派です。