This is really a simple argument.
Any of the options will work properly if all developers follow the same standard.
Any of the options will fail miserably if some developers follow the same standard, but others don't.
Only the third option, tabs for indentation plus spaces for alignment, will allow developers to change the number of spaces per indent to their personal preference without screwing up the code. A guy who likes 2-space tabs can set his personal view to be two spaces, while a guy who likes 8-space tabs can do the same. The code will still be perfectly indented either way, and using tabs+spaces even multi-line function calls will still line up no matter what your tabstop value is.
If you just use tabs, you still get the same benefit of not imposing one man's personal tabstop value preference on all, but multi-line function calls will no longer be aligned for non-standard tabstop values.
If you just use spaces, you are forced to impose one man's will on the crowd, like a new web developer who doesn't understand CSS.
This is all in the theoretical world where people follow the coding standard. In that world, tabs+spaces is the clear winner. In the real world, where people always forget about the standard and screw up, tabs + spaces is just too darn complicated for some people to understand, increasing the likelyhood of nonstandard code. Spaces-only goes from being the worst option to a potential winner because you can at least override a non-standard tabs-user by automatically converting tabs to spaces on checkin. However, you could convert spaces-at-the-start-of-a-line to tabs just as easily, so there's really no case where spaces are the winner.
Tabs are always going to win the day due to allowing fussy developers to view code in their own personal tabstop preference. Spaces just can't do that. Spaces are great if you believe your personal viewing preferences are The One True Way, though, and you'd like to force everyone else to follow them.