OK that's a slightly weird title. Anyone who comes across that may wonder why I slapped "Opinion' on the front. The reason is simply that I didn't wany anyone who saw it in passing to be misled into thinking I was passing on a statement from Microsoft for example (who have not said anything of the kind).
So in short, it's my opinion that if you can afford it, it's a wise move to go with the whole shebang including VSTFS rather than Sticking With SourceSafe Because That's What We Know.
I'm not going to go into the deficiencies of VSS, or the benefits of the Source Control part of Team Foundation Server (except possibly in a very tangential way).
I'm also not going to be saying much about the benefits of the new non-developer skus (especially since I think some of the decisions about what goes in which have been marketing-driven and less than helpful).
Nope, the point I want to make is that the ability to create a Team Project (with all that that entails) and apply things such as check-in policies actually brings considerable benefits to any team consisting of more than one person. The benefit for small teams comes from offloading much of the burden of enforcing process and standards onto the tools.
In my current position, in addition to development responsibilities I am responsible for architecture and standards (as well as a lot of nannying). The less time I have to spend marking people's homework the better, and the happier we'll all be. Too often also I've been confronted with an argument that boils down to "we don't have time to do it properly" (to which the obvious reply is "we don't have time not to"). And frankly, I think anyone who does code reviews (or production support) would rather find themselves asking "how did you do that?" than "why did you do that?". From this point of view something as simple as being able to make static code analysis a check-in requirement (and specify what's included, what counts as a warning and what counts as an error) is a Godsend. Not only does it save a lot of time, but it ensures consistency. And the great intangible benefit is that by making it the tool that says "you can't do that", it's possible to remove a lot of unnecessary friction (or at least redirect it to an inanimate piece of software).
Obviously code analysis is not a substitute for code reviews, but it means that a lot less time has to be spent on points like the application of naming standards.
Similarly, the ability to integrate your chosen process and its required artefacts tightly with the project life cycle makes the process more consistent, easier to follow, and more likely to be followed.
Which is nice.