Because spaces are guaranteed to layout the text to a predictable format, whereas tabs are not since the size can be adjusted and tab-stops don't necessarily line up with obvious word boundaries on the lines above.
The correct way to use tabs is to indent with tabs and align with spaces, that way everyone can adjust the tab size to their liking without breaking alignment.
Then you've got mixed tabs and spaces, which seems like it's going to inevitably lead to confusion when someone who isn't aware of the convention starts to make changes. Two different invisible characters in a single file is a recipe for madness.
I've been writing (and reading) a lot of Lisp lately, and have seen some projects adopt indentation idioms which offset blocks from the regular tab-stop intervals. A standard tab-stop might be +4, but then arguments might be lined up with each-other at +6 (+1.5 stops):
(list 'a
'b
'c)
Any of those arguments could be forms, which might return to the standard tap-stop of +4 but off by 2 (let's call that `+4(+2)`):
(list 'a
(with-foo quz
(bar quz))
'c)
Lists written with the `quote` syntax might do the same thing, but produce an offset of only 1:
'(a
(b
(c)))
The end result is that changing a code's indentation level (like when raising an anonymous function into a top-level definition) means adjusting the spaces (which were supposed to only be for alignment) if any preceding forms had introduced an offset. The alignment doesn't change, but it's relation to regular tab-stops does. Sometimes, this is an adjustment of zero, but you still need to think about it. In an all-spaces environment you could use vim's visual mode to select the block as a rectangle and paste it into the top level, but with "indent/align" semantics this same situation regularly requires maintenance (by inserting or removing spaces, in addition to manipulating indentation via tabs) to preserve both proper alignment and the integrity of the semantic distinction[1].
I think that elastic tab-stops fix this by correctly modeling indentation is it should be conceptualized, platonically divorced from the characters encoding it. I think that spaces are better than tabs when white-space isn't significant (and personal style might disregard tab-stops), but recognize that tabs are more accessible and worth using when tab-stops are enforced as a byproduct of significant white-space. I repeat that elastic tab-stops are awesome.
1: Someone correct me if vim can actually just do that with tabs just fine, i dont really know, it late~
That doesn't work when alignment depends on the tab size like aligning an indented line below an unindented line like long assignments
Type myvar = something_very_long +
that_needs_alignment;
The only way to guarantee such complex alignment is using spaces. It renders everywhere exactly the same. So reviewing stuff on web-based environments gets easier.
“correct way”? This is just your opinion. Everyone has one. Want to read mine? “A text editor should never replace what I type”. Want another opinion? “An editor should always distinctively display white-space characters”.
If someone finds it more readable to have their tabs smaller to fit on a small screen, or larger to fit on a large screen, why deprive them of that?
It’s perfectly fine to still have a canonical width if you want to use it for other reasons, like Linux with their “tab is 8 spaces when deciding whether a line is too long” thing.
May as well mandate a specific font and color scheme if the goal is to control how other people view code.
Tabs are self-consistent, which is usually all that matters. If for some reason you need greater control (E.G. ASCII-art spanning multiple indentation levels), then that should be documented instead.
