Let me first say that, as far as I'm concerned, this whole debate is scoped to languages where exact indentation is only a formatting aspect of which the compiler/processor is largely oblivious (the vast majority of languages). I know there are some languages out there where the exact horizontal placement of a line in relation to another carries semantic significance, but for all practical intents and purposes (especially within the context of the Orchard CMS codebase) let's leave those esoteric aspects aside.
With that out of the way, I think perhaps the best way to express my view on this topic is by addressing in turn the two common arguments I hear from spacemen (my term-of-endearment for developers who believe spaces are a better indentation choice).
Spaceman argument #1
"Spaces make you view the code as the author intended it."
The argument here being that if another developer views the code file with a different tab size setting, the code will not look exactly identical on her screen as it did on mine when I wrote it. The basic premise for this argument is silly to begin with. A code author does not (or at least should not) indend to impose her personal viewing preferences on anybody else. Encouraging or enabling her to do so is not a good thing.
If you want to force other developers to view your code exactly as you wrote it, you should create a PDF. :)
Let me elaborate a bit on why.
There is a good reason why we use text files to store source code, and why we like to use flexible and capable editors (like the one in Visual Studio) to work with source code: we all have personal preferences in how we want source code to be displayed. Some source code viewing preferences that most of us appreciate include:
Sometimes these choices are based on habit or personal preference. Sometimes they are based on context or circumstance such as screen size, lighting conditions, etc. Sometimes they are based on disabilities such as vision impairments. And sometimes they depend on what kind of viewing I'm doing (e.g. am I comparing two files side-by-side or am I getting oriented in a huge new codebase?)
But these choices all have one thing in common: they change how the code is displayed. And that's a good thing! As far as I know, most developers appreciate these abilities to tailor the viewing experience to their liking. I have yet to hear even spacemen argue that any of these aspects should be preserved "as the author intended the code to be viewed".
Indentation size is no different: it really is purely a viewing concern and as such should be up each individual user to customize. It is every bit as much subject to the same matters of personal taste, context, circumstance and possible impairments as any other visual preference.
So why do so many developers think of indentation size differently? Well, I think the spacemen who make this argument might fail to recognize the difference between indentation level and indentation size. Indentation level is structurally relevant, it communicates something about the code and should definitely be considered part of the code and how the author intended it, and editors should represent it with full fidelity - no objection there. But indentation size (i.e. how many pixels wide do I want one indentation level to be on my screen) is not. That's a matter of visual preference. It doesn't matter to the structural representation of the code whether indentation levels are 2 characters wide or 4 characters wide. The visual structure remains the same, it just becomes more or less pronounced visually depending on my setting.
Spaceman argument #2
"OK but indentation isn't always structural, sometimes it's used to align things!"
What spacemen mean by this argument is that they have acquired the unfortunate habit of writing code like this:
SomeNiceMethod(parameter1, parameter2, parameter3);
Here's the thing though: using indentation this way will give you grief and extra work even if you use spaces to do it. You want to rename the method
MyMethod? All right, go ahead. You will end up with this:
MyMethod(parameter1, parameter2, parameter3);
And now you'll have to go and manually fix up your indentation. The same goes for method declarations, lambdas, or anything else where you start an artificial indentation level on an arbitrary anchor point of a previous line. On any teams or projects where I have any influence over this, I ask people to not use this type of indentation, i.e. do not base the indentation of a line on any other anchor point of a preceding line than the *start* of that preceding line, because all other anchor points are moving targets.
Instead, I encourage people to use this style:
SomeNiceMethod( parameter1, parameter2, parameter3);
And I want to reiterate: the reason for this principle applies regardless of whether you use tabs or spaces. And if you follow this principle, then spaceman argument #2 ceases to exist.
So there, I said it. Once and for all. :) It's out there. I'm not a spaceman, and these are my reasons.
Having said all this, I should point out that I recently proposed formalizing on a set of formatting guidelines for the Orchard CMS codebase, and part of my suggestion is to use spaces (*gasp*) because it's what's used in most of the code, and I know most of the people working on the code prefer it. Which brings me to my closing point: the most important thing for any code base is consistency, so whether your team or project prefer spaces or tabs for indentation is of little importance compared to the importance of making a choice and applying it consistently.