タブインデントの最大のデメリットとしては、正しく使えるユーザ数が極端に少ないということでしょうか。

miu_ras 様が、予め断っているにも関わらずインデントと位置合わせを混同する意見などが散見されますし、同じく論点のずれた意見が「タブスペース論争」の検索結果でも同じような記事はたくさん見かけます。

つまり正しく理解して、それを使える人間がごくわずかしかいない。
→ 正しく使えないのであれば、スペースの個数を指定するというごく単純なルールだけによる運用のほうがスムーズである。
というのが世間の流れではないでしょうか。

しかしながら、この後ろ向きな風潮は、エンジニアとしては残念でたまりません。
かつてXPを使っている人がいるからという理由で、レガシーブラウザ対応し続けてきたWEB業界のような、とても後ろ向きな標準化であると感じてしまいます。

せめてタブ派の方々だけでも、インデントと位置合わせの違いぐらいはきちんと理解して、スペース派に余計なツッコミを入れられる状態をなくしていけたらもう少し市民権を得られるのでは？と思います。

良いエディタと、EditorConfigによる適切な設定、適切なフォーマッター、適切なリンター、適切な表示設定をしていればどっちでも何も問題ないと思っています(タブに制限や非推奨の理由がある一部の言語を除く)。

・半角空白を複数で1インデントとすることにより、少ない文字数で表現でき、ファイルサイズが小さくなる 

ソースコードのファイルサイズが小さくなることにメリットはほとんどありません。コメントを入れない方がファイルサイズが小さくなって良いなんて誰も言わないのと同じです。

また、HTML、CSS、JavaScriptは最終的に圧縮(minify)するのが普通なので、インデントに何を使っていようがファイルサイズは一緒です。

・1インデントが正しく構成されているか一目でわかる 
 →例えば半角空白4つで1インデントとするルールで、3インデントのはずの個所で半角空白11個とか13個で書かれているケースをしばしば見かけるが、ぱっと見ただけでは正しいインデントなのか判別しにくい 

良いエディタを使っていれば、インデントラインが表示できます。スペースだろうがタブだろうがインデントのずれはすぐにわかります。

・タブならエディタの設定で、自分の見やすい表示幅に調節できる(ことが多い。エディタによるが) 

タブだからこそ幅を指定しないと、想定幅をこえてしまい、見難くなります。むしろタブの場合は、EditorConfigでタブの幅を指定すべきです。結局EditorConfigで指定すれば何も問題ありません。

また、自分の好みのインデント幅で無ければ、好みになるようにフォーマッターを使えば良いだけです。

・インデント中をカーソルで移動する際やインデントを削除する際に、少ないキー押下回数で済み楽に操作できる 

まともなエディタはインデント幅を一回で移動したり削除したりできるようになっています。スペースもタブも関係ありません。

・エディタの表示設定で、半角空白・全角空白・タブを表示するようにしたときに、半角空白でインデントをしているとうっとうしい 
 →「半角空白・タブの混在」や「全角空白の混入」を避けるために、非表示文字も見分けがつく設定にしておくべきだと思う 

そもそもうっとうしい表示にしかできないようなエディタが悪いです。表示が控えめであるか、自分で調整できるのが良いエディタです。なお「全角空白」が表示できないようなエディタは使う価値がありません。

・半角空白でインデントを表現する場合、2個派と4個派とその他派で対立が起こる 

タブでも2幅派、4幅派、8幅派の対立が起きます。ただ、何幅派の人が作ろうが、フォーマッターでフォーマットすれば良いだけなので、みんな仲良く過ごせるはずです。

ということで、どっちもどっちだと思います。

そもそも言語によってインデントが2幅、4幅、8幅のどれが良いのかは異なると考えています。2幅だとわかりにくい言語もあれば、8幅だときつい言語もあります。ただ、スペースであろうがタブであろうが、適切な設定とフォーマッターやリンターがあれば、言語毎の切り替えもできるので、何も問題は無いと思います。

【最近の悩み】

C++は8幅のタブでインデントしているですが、public:とprivate:とかをどうインデントすべきか悩んでいます。今はスペース4文字にしているのですが、スペースとタブが混ざってすごい違和感が…。

class A {
        int num; // タブ1文字8幅(ここではスペースで表現しています)
    public: // スペース4文字
        int GetNum(); // タブ1文字8幅(ここではスペースで表現しています)
};

「混在させるのは論外」とのことなので、私のような人の回答はそもそも論外になるかと思います。

タブのデメリット
・Githubで8文字に表示されるので見るに堪えない

並び順が回答の都合上悪いのであべこべに回答しますよ。
あと、全部のレスをさっと読んで、感覚的な話だなと思ったので感覚的なことを書きます。
私はタブインデントが大嫌いですからその理由を感情的に書きます。
コメント上の貴方はかなり情熱的な感じなんで、その方がなんか貴方と話し合える気がしたからです。

(3)現実問題として問題が発生することはあるか。あるなら具体的に。 

この話はインデントそのものとは関係ないことに注意してください。

まず、単純にタブ文字そのものに困ったことが私はあります。
成熟していない米国の開発環境のエディタが2バイト文字に対応しておらず、日本語の右にタブを入れるとインデントがズレてしまうというのに遭遇したことがあります。
これには困りました。

ShowDialog(
    "確認",              // タイトル
    "CSVを出力します。");    // 本文

これ、自分にとっては「タブの本質的な問題」そのものなんですよ。
エディタが悪いっていうかもしれないけど。
複数人で作業するだけでなく、エディタも含めて読み手側に制御をゆだねるような作りが私は好きじゃありません。
タブ文字っていうのは、マジックナンバーと同じで、正当な扱いを書手と読者両方に求めてる奴です。

プログラミングを初めて1年の間は好んでタブ文字を使っていました。しかし、私個人はこの経験を経てタブ文字そのものがノイズであるという認識に変わりました。

(1)インデントにタブを使うことにデメリットはあるか 

まずタブ文字が「画一的でない。状態が固定されていない。」というデメリットを持っています。
「読者が好きに幅を設定できる」はメリットではありません。

タブ文字を使うことによる、動作上のデメリットは今となってはほとんどありません。
エディタから見ればタブも空白もただの文字です。
しかも、タブ文字の利用が貴方の内容なら相当限定されている。
この限定条件下でインデントそのものがタブかどうかははっきり言ってほとんどの読者には関係ありません。
貴方のやり方なら人間の目から見て即座にタブとスペースの互換に問題も起きないでしょう。

しかし。ですよ。
だからこそタブでインデントしたらデメリットがあるかと言われれば、私は「ある」とはっきり言いましょう。
なんでそこまできっちりこだわったのに、インデントが「可変長」なのかがまったく理解できません。
可変長インデントじゃなくて、固定長インデントでソースコードは共有してほしいんですよ。

プログラマーはどうしたら読みやすいかについて頭をひねってコーディングします。
重要なのはインデント幅から受ける書き手としての感覚的な影響です。
タブ文字で整形をしてしまうと、「組んだ誰かにとって最適であったような状態」が読む環境でブレてしまいます。これはね、「2/4/8文字タブスペースの問題」とかじゃまったくないんです。
「こいつは…タブ幅2文字だったのか？4文字だったのか？」この悩み自体がナンセンスです。
2幅で書いたソースは2幅で最初から見えているべきなんですよ。

タブは言わば、ソースコードの共有時に紛れ込む唯一の脆弱性です。
受け手によって見た目が変わるなんて存在そのものが不合理です。
タブ文化っていうのは、それ全てが言わば書き手と読み手の蜜結合です。
これが私には、酷く醜いものに見えます。

(2)インデントに半角空白を使うことにメリットはあるか 

私たちは皆物書きです。最高の見た目でコーディングします。
そこで「タブ幅の自由」みたいな話題を読者側の私に振るなと。
むしろ自由なんだ。好きに設定してくれ。必要であればインデント幅なんていくらでも改変してコードは読む。
だから、書き手のお前が2幅が良いと思ったなら2幅で見えるようなものを提出しろと。
最初の一歩として、私は貴方が書いた時に見ていたものをそのまま見たいわけです。

少なくとも、空白埋めにはそういうブレの入り込む隙がありません。

終わりに

といっても、まあ実のところタブ文字で提出されて困ることはほとんどないはずです。
貴方ぐらい神経質に拘って書いてるなら特に問題は起きないはずです。
それが読みやすいかどうかは、ソース見なきゃわかんないもん、文句のつけようもありません。

確かなのは、タブってのは曖昧ってことです。
むしろ貴方ぐらいちゃっかりかっちりを求めているのに、なんでタブはOKなんだって疑問で私はいっぱいです。

インデントにタブの使用することに関しては致命的な欠点はないという点は同意です。プログラムを書く場合は Xcode のように折り返しも含めてエディタが面倒を見てくれるのが理想ですよね。

今さらですが、ここでも他所でもあまり触れられていないスペースのデメリットがあるので述べたいと思います。

おそらくスペース派の方は、コードを編集するときに使用するフォントは固定ピッチであることが前提条件になっていると思いますが、すべての方が固定ピッチフォントを使用しているとは限りません。少なくとも私はそうです。

固定ピッチフォントでは、スペースの幅は所謂全角の 1/2 か、欧文専用のフォントだとそれより大きいくらいですね。なので、2スペースや4スペースがちょうどいいという話をよく聞くわけです。

しかしながら普通の欧文フォントではスペース幅は所謂全角の 1/4～1/3 程度の幅です。この時点で「環境に左右されないようにする」という意図は意味をなしていません。行中の位置揃えは言うまでもなく、行頭のインデントに関しても環境によって表示は変わってきます。

以上のような理由から、エディタで幅を変えられるタブを使うほうが親切だと思います。

追伸）昔は diff, patch コマンドでタブを扱えないからスペースにすべきという意見もありましたね。

こんにちは。

盛り上がっているようなので、ちょっとだけ意見を述べさせて下さい。

(1)インデントにタブを使うことにデメリットはあるか 
(2)インデントに半角空白を使うことにメリットはあるか 
(3)現実問題として問題が発生することはあるか。あるなら具体的に。 

(1)と(2)は「下記２つの条件を満たす場合にある」です。

1. そのソースを見る人の間でタブ幅を固定する合意が取れない
2. ソースを見やすくなるよう工夫する際、行中の桁揃えも採用している

1.は、オープンソース・プロジェクトは常に該当します。
2.も、成立することはそこそこあると思います。

私自身は、ソースを視覚的にもすっきり見えるよう工夫したい人なので、行中の桁揃えを気にしてコーディングすることが少なくないです。（インデントの深さが異なる行の間でも桁揃えします。）
そのようなソースを公開することがあるので、タブ・コードは使いません。
折角頑張った桁揃えが、見る人のエディタの設定により崩れるのは悲しいですから。

行中の桁揃えをするようなソースを書かない場合は、タブ・コードを使っても問題はでないと思いますが、桁揃えすると見やすくなる時に桁揃えしていないソースって不親切だなとは感じます。ま、絶対嫌と言うほどの拒否感はないです。

(3)のタブ・コードを使った場合の問題は、「桁揃えしたソースを公開すると恥ずかしい」、もしくは、「桁揃えしないちょっと見づらめのソースしか公開できない」ですね。

そして、オープンソースの世界ではスペース派の方がかなり多いようです。

自分は「よく使われる画像」の中の叩かれる人です...

ただ, 実際のところ自分としては「インデント」にはタブしか使っていないのです.
ですが「視覚上の位置合わせ」にスペースを使う人間なため,
「インデント」に限らなければ「タブスペース混在」なので叩かれる, という構図です.

参加する場合はそのプロジェクトに合わせますが, プライベートでは ([TAB]=タブ文字, _=半角空白):

//※あくまで説明のためのコードですのであんまり良いコードではないですが.
[TAB]///_コメント
[TAB]///_a___引数a
[TAB]///_bb__引数bb
[TAB]///_ccc_引数ccc
[TAB]int_func1(int_a,_int_*bb,_int_ccc)_{
[TAB][TAB]func2(a,
[TAB][TAB]______bb,____//※1
[TAB][TAB]______ccc);__//※1
[TAB][TAB]
[TAB][TAB]if_(a_<_0_||_ccc_<=_a)_return_-1;
[TAB][TAB]else___________________return_func3(bb[a]);
[TAB]}

インデントと位置合わせはこのように完全に別物として区別したいのです.
ただこれ, サポートしてくれるエディタがほとんどないのが苦しいところ...
※1なんてインデント調整の操作したらどっちか片方に統一されてしまったりしますし.

• 表示がずれる

extra_args_func('arguments1'
               ,'arguments2'
               ,'arguments3');

• 1タブ=8スペース前提になっていることがある

• めんどくさい

古い記事ですが……。

自分はスペース派からタブ派に変わった口ですね。
結局、タブでのデメリットは「見た目」だけだったんです。
テキストエディタの融通が利かない、投入するサービスの融通が利かないなど。

しかし使ってみるとTABの方が自由度は高く、見た目も自在に変えられる。

例えばスペースである方が都合がいい時は、TABをGREPすればすぐにスペースに置き換えられます。
しかし、スペースで書いてしまうとTABに変更するのは行頭から2文字ずつという置き換えが必要になり
、負荷も時間も掛かりますしミスの可能性も増大します。

そもそもスペースはインデント以外でも多様しますが、TABをインデント以外で使うことは皆無ですもんね。

メガ単位のファイルなら大したことないんですけど、ギガ単位を超え始めることが多くなりスペースの容量がバカバカしくなりました。
Googleほど潤沢なスペックやリソースがあればいいんですけど（笑）

インデントにはTABを、インデント以外の桁揃えにはスペースを使うデメリットですが、それをすべての人が守れるようにするのが難しいというのがあります。

例えば、エディタにもよりますが、TABキーを押したらTAB幅に合わせた桁揃えをし、
そのときに使う文字としてスペースを使うかTABを使うかが設定できるようになっている事が多いです。
その場合、インデントをTABでするにはTABキーでTAB文字を入力する設定にする必要があり、
桁揃えにTABキーをついつい使ってしまうとインデントじゃない場所にTAB文字が入ってしまいます。

なので、特に多人数が関わるときは、インデントとインデント以外の桁揃えでTABとスペースを
適切に使い分けるよりも、スペースだけを使う方がずっと楽になります。OSSでスペース派が多いのは
この理由が大きいと思っています。

なお、 Go は標準で賢いコードフォーマッタ (gofmt) を用意することでこの問題を解決して、
TABインデントを標準にしています。
Go を使っていて TAB インデントが辛くなるのは、ブラウザ上でコードを書く
（こう言うフォームとか gmail とか）ときにTABキーが普通に使える事が少ないことくらいです。
そんなときばかりは、Goを書くときでもスペースでインデントしてしまいます。
（コピペされても、その人がちゃんと gofmt かければ解消されますしね）

タブを使うのと何カラムごとにインデントするかはまた別ですね。

私は古いので、スペースタブ混在です。12カラムインデントならタブ1文字とスペース4文字。これはエディタがそういうふうに勝手にしてくれます(行の頭から8の倍数カラムはタブにして残りはスペース)。

GUI時代以降はタブが何カラムにあたるか想定できない時代になったので、
・複数人でソースを見る
・タブ設定の統一化を強制できない
という状況だとスペースのみを使ってインデントしないと共同作業に困ると思います。

タブを使った方がソースプログラムが短くなるのは、今どき利点とは言えないでしょうね。

行中の位置揃えや装飾を「インデント」と呼ぶ人もいるようなのですが、本質問では無関係とさせてください。 

「インデント」の直後で「前の行の文法要素に合わせた位置揃え」を行う場合、すべてタブで行おうとしても、揃えるべき桁がタブだと中途半端な位置になって、目的の位置に入れられないということが発生します。この状況でタブとスペースの混在を許さないとすれば、インデントもスペースに揃えるしか手段がありません（さすがに、行頭から連続するスペースに対して「インデント分だけタブにして、残りはスペースで」というような打ち分けは難しいでしょうし、エディタで自動判定するのも困難だと思います）。

AirbnbによるRubyのスタイリングにも、途中の位置揃えをするスタイリングが入っていますが、全体のインデントは2スペースとなっています。

module SomeModule
  # 奇数桁なので、スペースで位置揃えするしかない
  def self.some_method(phrase_id,
                       phrase_key,
                       target_locale,
                       value,
                       user_id,
                       do_xss_check,
                       allow_verification)
    ...
  end
end

私は、正直迷っています。
個人的にはタブを使用したいのですが、やむなく空白を使用するときは2文字派です。
最近老眼が進み、文字を大きく表示して作業しますのでインデントは2文字で十分になりました。
文字が小さいときは4文字でないと見にくいかもれません。
このような変更がタブ文字なら可能なのですが、以下のような事情もあり、結局、プロジェクトによって変えているのが現状です。

タブ文字の表示方法が定まってなく、さらに、デフォルトでタブ文字が空白8文字として表示されることが多い?ことも問題があるように思います。

エディタだけではなく、ツール類もあるわけで、このデフォルトを変更する一手間が非常に高いハードルなんです。

お客様の環境下で作業をするとき、むやみにツール類の設定を変えることはNGです。 ましてや、お客様に、「見にくかったらタブの設定を変えて下さい」なんて言えないのです。
また、システムの奥深くにある古い融通の利かないツールなどを利用するとき、設定自体が不明またはできないなど不幸に遭遇することもあります。 そういうものに限って、外せない理由があったりします。
勢い、表示環境に左右されない空白文字をインデントに使う無難な道を選ぶことになります。

また、タブ文字を一切使用しないと決めると、「インデントにタブを使うことのデメリット」の話に限定するようなこともなく、「コメント欄の位置揃えにはタブ文字は使用しないでね」とわざわざ注意喚起する必要はありません。

タブは、タイプライターのタブキーからの由来で、本来タブ文字なるものはなく、印字ヘッドの位置決めに使われていたものです。 印字ヘッドを元に戻す操作:キャリッジリターン(CR),１行紙送り:ラインフィード(LF) と同じ部類(制御文字)に入ります。現在はほとんど使用されていない、垂直タブ,バーチカルタブ(VT コード0B)もまだあるくらいなので、位置決めに使うなと言っても、本来の目的が位置決めから始まっているので、伝わりにくいかもしれません。

さらに、プログラムだけに話を限定されているように思いますが、データにも階層構造があり、このインデントに空白を使うかタブを使うかは、読み込むプログラム側の実装依存になり大きな問題になります。(プログラムソースもコンパイラのデータですが・・・)

ほかの回答をざっと読みましたが、質問者さんは「インデントにはタブを使うもので、スペースではインデントができない」という信条をお持ちのようにも見えます。もしもそうだとしたら、実際はそんなことはないです。

適当なCのソースコード (内容はでたらめ) を、GNU indentで処理してみると、結果は次のようになります。

void
func (void)
{
  while (i)
    if ((((i < 2 && k > 0)
________  || p == 0)
________ && q == 1) || n = 0)
      {
________i--;
      }
}

なお、結果をわかりやすくするため-l30オプションを与えています (ほかのオプションはないです)。また、結果に現れるタブ文字を「________」で表しています。

ここで注目してほしいのは、

• 制御構造よりも微細な構文のレベルに応じて、1文字単位の字下げを行う流儀もある (||や&&に注目)。
• 基本的なインデント幅が8文字でなくても、字下げの手段として一定幅 (ここでは8文字) を表すのにタブを使う流儀がある。

という点です。なお、これは比較的歴史のあるindentというツールの初期設定 (行長を除く) を使った結果ですから、このような流儀が、一般的でない特定の環境を前提としているとは考えにくいです。

ちなみに、「スペースを使うとスペースの幅の整数倍がタブと同じにならないことがあるから、インデントにスペースを使わない」あるいは「タブとスペースを混在させない」といった主張をされるかたがあるのでしたら、ちゃんと幅が同じに表示できる環境で作業することをお勧めします。

個人的には、かつて長い間、言語を問わず「4文字単位のインデントをするが、8文字分を表すのにはタブを使う」という習慣を持っていました。

しかしあるとき、複数人で共同でプログラミング (お金をもらう仕事以外で) した際に、「4文字単位のインデントをするが、タブ幅を4文字に設定しているのでタブでインデントしている」という人や「タブは一切使わないがインデントは4文字単位 (タブの表示幅は8)」という人、しまいには「インラインコメント (行末につく一行コメント) もタブでそろえる」という人などがいて、収拾がつかなくなりました (一つのソースを「一人目の人」、「私」、「二人目の人」の順で編集したらどんな悲惨な結果になったかは、ご想像にお任せします)。

結果どうしたかというと、次のように決めました。

• 幅の解釈に相違が生じるタブ文字の使用は推奨しない。
• コミットの際のインデント幅や改行ルールは各自の自由。
• ただし、リリース前にソース整形ツールで形式を統一する。その結果にはみんな文句を言わない。

ともかく、個人的には現在、タブを使わないほうに宗旨替えしています (インデント幅は4のまま)。理由のひとつは上のように、タブ幅が人によって一定しないことに懲りたからです。

もうひとつの理由は、当ページでもすでに実例があるように、入力時にタブ文字が無視される事例が増えている (ように思う) からです。これは、タブキーがしばしばアプリケーションのウィジェット間の移動に用いられるため、それとの干渉を避けるためではないかと考えています。

私はJavaScript(AltJS)は2スペース、PHPはタブ派でやっている特殊な例（というほどでもないか？）です。
エディターで使いやすいか否かが質問文のメリットにあるので
スペース派もエディターの設定等で対策出来る範囲は対策出来るという視点で質問文に対してちょっと気になるところに触れてみます。

• 1インデントが正しく構成されているか一目でわかる
  →スペースだからといって増えたり減ったりする輩はタブでも1文字だけスペースが紛れ込んでるとかで同じ事やらかすのでノーコメントで…
  →PythonやCoffeeScriptなどの言語は2スペースで安定運用します
• エディタの表示設定で、半角空白・全角空白・タブを表示するようにしたときに、半角空白でインデントをしているとうっとうしい
  →スペースインデント派は半角スペースのみ非表示にします。それでなれるとタブがうるさく感じます。
• 半角空白を複数で1インデントとすることにより、少ない文字数で表現でき、ファイルサイズが小さくなる 
  →基本的にはその通りですが、タブも\tと2文字文消費するので常にファイルサイズが小さい訳ではありません。
• インデント中をカーソルで移動する際やインデントを削除する際に、少ないキー押下回数で済み楽に操作できる 
  →エディターの設定次第で、ソフトインデントのファイルに対してタブと同じような操作が出来ます。

残った2つがでかいですね、
おっしゃる通りスペースは後から気軽に増やしたり減らしたりが難しいですからね。
Tabならば喧嘩が起きないですね。

・タブならエディタの設定で、自分の見やすい表示幅に調節できる(ことが多い。エディタによるが) 
・半角空白でインデントを表現する場合、2個派と4個派とその他派で対立が起こる 

他回答では挙げられてない点として、
エディターに於いてはTab≒インデントに使われる文字という認識が一般的ですが、
何らかの機能として実装されているケースがあり、Tabインデントが使えないケースが挙げられます。
（辞書登録したり、コピペで対応すれば入力することは可能ですが…）

• WebサイトのテキストエリアでTabキーを押すと、次のフォーム部品にフォーカスが移る
• Bash等でCat文を作ってる最中Tabがパスの補完として機能する

$ cat << EOS > hoge.txt
> [Tab] // カレントディレクトリのファイルの補完になる

Eclipseだとコードフォーマッタがあるので、プロジェクト参画時に適用してもらってタブ・半角スペース・タブ幅の統一はしますね。
あとは保管時アクションも、チーム内で揃えますね。

タブでインデントする際には特に目立ったデメリットはないでしょう。
あえてデメリットとするならば、タブ文字を画面に表示する際に半角スペースで自動変換するサービスでは、表示する際には何らかの文字幅を設定しないと表示が崩れるくらいかと。

別件ですが、CSVを扱う際には区切り文字をタブにするシステムもありますので、タブ文字をコードに入れるのを嫌がる人は一度だけ遭遇したことがあります。

Linuxの設定ファイルの話はお呼びでなかったらすみません。
（質問では「一応このあたりをターゲットとしていただきたいですが、上記以外でも「この言語ではタブではエラーになる」 等の情報がありましたら教えていただきたいです。」とのことなので、テキストエディタで扱う対象の一つということでお許しください…)

(3)現実問題として問題が発生することはあるか。
についてです。

例えば、Raspberry PiのRaspbian、の/boot/config.txtですが、Githubにある説明では、

N.B. When editing this file, please preserve the indentation levels to make it
simple to parse programmatically. NO HARD TABS.

って書いてありまして、ハードタブ入れるんじゃないよ！って書いてあります。
ソフトタブだけしかインデントには使えません。

ブート時に読み込むファイルなので、余裕がなくてそういう制約がきついのかもしれません。

最近はソフト屋さんが以前の様なITリテラシーの高い人だけではなくなりつつあり、タブとスペースの違いが分からない人、気にしない人などがいます。それくらいプログラミングの敷居が低くなっています。
それに従いスペース派が多くなってきています。以前はスペースとタブが区別できるようにエディターを設定にしてましたが、混在しているのが気になるので、タブとスペースの区別がつかない設定を使用するようになりました。

1人で開発する分には当然タブで困る事はないですが、今はBoth派です。プログラミングは各人の効率を上げる事が重要だと思うので、各人が快適にコーディングするのが良いです。
コーディングする前に自分が好きな形式に整形するフォーマッターを適用して、コミック前には組織のルールに整形するフォーマッターで戻すのが良いかと思います。

デメリットはケースバイケースでしょう。
共同作業者がタブインデントを日常的に使っているところにわざわざ半角スペースインデントを使うメリットはないですし、使っているまたは使う予定のエディタのデフォルト設定がタブキーにタブが割り当てられている場合は、半角スペースに設定し直す煩わしさはデメリットになります、逆も然りです。設定変更可能でデフォルトの値が何かという意味に一度頭を巡らせてみるといいです。エディタの作者がそれが必須だという考えならそれがデフォルトから外れているはずがありませんよ。

デメリットはケースバイケースです。

圧倒的に生産性良いのはタブですが説得が一番の問題です。
インデントなんだからタブが普通だし、スペースで凝り固まりすぎです。
非効率極まります。

スペースでの問題点
・ファイルのサイズが大きいことで重く大規模プロジェクトで調査とかをするとGrepに時間が
・スペース入力の手間が大きい
・SQLをログ出力していると圧縮できずそのままのスペースでるからログ肥大化して調査も手間
・よくずれる
・html圧縮する必要あり
・圧縮した場合ブラウザ上での解析が必要なシーンで厄介なので基本的にはそのまま使った方が良い。外部に公開するときは難読性を高めるため圧縮した方が良い。

タブでの問題点
・すでに広まってしまったスペースを標準とすることが多く、凝り固まった人達を説得しづらい
・エクセルに貼るときにsakuraでスペース置換必要
・iphoneで打てない

タブと混在させたいケース
↓これ
select
Aaaa
,Bbbb
From
のようなときに一行目を混在させるほうが綺麗です。

• インデントを表現する文字コードとしてタブを使う
• インデント1段を表現するためにタブキーを打つ/ファイルにタブ文字を入れる。つまりインデント一段はタブストップ1つ分のカラムにひとしい

という二段階の話がありますね。

私はタブは8カラムに決まってるだろ派ですので、結構タブをインデントも使います(12カラムにインデントするならタブ1つ＋半角スペース4つ=viでインデント機能を使った時の挙動)。
結局タブでインデントすること自体に支障はないが、他人に渡したり共同作業するときには支障が生じる。特にタブ幅のカスタマイズが異なる人相手だと困る。ということでしょう。

teratailにキーボードからタブを打って入れられない(僕が知らないだけで実はできる？）という不便もあります。

なお、紙テープにはタブコードは入れられます。

スペース2つがベストだと思っています。
タブやスペース4文字だとgithubやエディタで見たときに行末が見えないので。

と、これは自分場合ですが、最終的にはタブでもスペースでもどっちでもいいとは思います。

人に優しく、チームに優しく、システムにも優しいなら。

ただ、最近のエディタはデフォルトでタブを打つとスペースになりますね。

世の中的にはそうゆう方向性になっているんじゃないでしょうか。

私は半角スペース派です。

言語は主に C/C++。

タブキーによるインデントのデメリット...

Eclipse や VC++ で開発されている方はあまりデメリットを感じないかと思いますが、

メモ帳や TeraPad というようなテキストエディタ+ コンパイラ で開発している者としては

"扱いにくい"。

たとえば、VC++でDLL ( Javaだと メインメソッドがない jar ファイルといったところか。 ) を作成し、
MinGW ( javaだと javac にあたる。 ) で実行ファイルを作成した場合、

DLLのソースコードをテキストエディタで見ると、インデントがバラバラになっていたりする。

たとえば、

VC++ では

int a,b;
for( int i = 0; i < 20; i++ ){
      a = i;
      b = a*2;
}

となっているはずなのに、テキストエディタでみると、

int a,b;
for( int i = 0; i < 20; i++ ){
             a = i; // ここがずれているように見える
      b = a*2;
}

という感じになっていたり...

あと、

タブキーを 視覚的に見るために _ に置き換えると

__a = 0;_// コメント!

となっているとして、

a = 0; の 0 の部分を書き換えたとします。( それとも // のところだったか? )

すると、若干ずれているように感じます。
( テキストエディタで編集した場合。 )

なので 半角スペースがいいかなぁと。

間違って投稿してしまったのですが、意見のまとめ用として使います。

■タブを使った場合に発生するデメリット
・Excelにコードを張り付けることを要求された場合に手間取る
・ドットインパクトプリンタでずれて印刷される場合がある
・ホストのCRT端末や初期のPC用エディタや、cat, less, vimなどだと、タブを使うとすぐに右端に達する
　→タブは8文字固定で画面幅は72桁しか表示できないため

■スペースを使うメリット
・パンチカードや紙テープではタブは使えないのでスペースを使わざるを得ない

□表示が崩れる説 (ただし、本質問の対象とはしない)
・行中や位置そろえ・装飾にタブを使うと作成者の意図と表示がずれる
 →「インデント」とは、「ネストの階層構造を表現するために行頭に非表示文字を挿入し字下げすること」と私は考えています。インデント以外にタブを使うことを許すかどうかはまた別の問題だと思います。世の中にはそういう対立問題もあるのかもしれませんが、本質問では「 インデントにタブを使うことのデメリット」だけを対象にさせていただきます。

・2文字で表示されることを前提としてコードを書いて、見た人が8文字で表示すると80桁を超えやすくなる
 →「タブとスペースの比較」では無く「2文字と8文字の比較」をしており本質問の意図と異なります。文字数対決は別の機会に行っていただきたいです

※タブ否定派の方から「行中の位置そろえや装飾にタブを使った場合に、別の人が観た際に作成者の意図とずれる」という意見を何度かいただきました。タブ肯定派の私から見てもそれに関しては正しいと思います。「行中の位置そろえや装飾にタブを使う」ことは避けるべきだと思います。

ですが、行中に使うべきではないという話と、「ネストの階層構造を表現するために行頭に非表示文字を挿入し字下げすること」は区別して考えるべきだと思います。

■その他
・YAMLではタブは使えない
・Pythonでは、タブを使っても特に問題はない。ただし、半角空白と混在状態になると正常に動作しなくなる