I would be interested in a good argument for spaces over tabs, because I just don't see the benefit of using spaces. The only reason you should ever be messing with source code is because you want to change what it does, not that you need to change how it looks. I get the feeling it has more to do with OSes historically freaking the fuck out if they find tabs in text files, causing this superstitious aversion to tabs.
Common Lisp has such strict indenting guidelines that they can be and are applied automatically while coding. The are never just in increments of tabs but rather in relation to their, uhm, parent node in the source tree. So they are either placed aligned with the arguments on the first line of the node:
(some-stuff foo (bar quux)
baz) ; note how this kind of indentation not only highlights how this belongs to some-stuff
; but also enhances the visibility of the arguments on the previous line
or, if there are no arguments on the first line, just to the right of the enclosing paren:
(yay
boo)
or, in some special cases one space further to the right, because these special constructs expect something multi-line there:
(progn
(one call)
(another thing to do))
(let ((a 2) ; variable definitions line up nicely
(b 3))
(+ a b)) ; the code is also easily distinguishable by the way it is less indented
This reads
very nicely, lines up things that belong together and so on. This wouldn't be possible with tabs.
For C++ emacs also does auto-indenting and uses different indent widths for different contexts. It makes code more readable because the offset conveys additional information.
So, the big advantage of spaces is the variability and thus readability. I don't want always 2 or always 4 or always 8 spaces for an indent level.