C-J: my sentiments exactly.
Jeff: in my mind “checkout” == “any source-control-specific-steps I have to take before I can edit a file that’s already on my hard drive.” Even if the IDE does this automatically for me, I hate the little delay when I start typing. And this only works in the IDE. I have to jump through all sorts of hoops if I want to make a change with Notepad.
Team System doesn’t do enough client-side tracking to provide a classic edit-merge-commit working style. Your link mentions that you should avoid off-line renames which I’m guessing is due to this not being tracked client-side.
There are a number of other issues I found with Team System when I researched it back in December. Subversion tracks changes at the directory level while VSTS only tracks per-file. You can’t exclude directories from source control in VSTS. All root VSTS folders must correspond to Team Projects. You can’t create a “simple” source-controlled folder in VSTS. VSTS doesn’t let you merge between unrelated branches, only parent-child branches. VSTS doesn’t have “blame/praise”.
In Subversion, the client keeps track of what files and versions you have. In VSTS, the server keeps track of what files and versions you have. This causes problems when moving stuff around on the client, but can speed up updates in “workspaces containing tens of thousands of files.”
In Subversion, “move” is implemented as “add with history and delete”. “Move” in VSTS is a thinly disguised alias for Rename. You also can only move one file at a time in VSTS.
Unlike Subversion, I’m guessing you can’t efficiently “switch” local files between branches, reusing the pre-existing client-side files, only transmitting and changing the diffs.
At the end of my post is Brian Harry’s response to my request for true edit-merge-commit. Notice that his goal is to stay firmly in the “checkout” camp even in v2 and convert people to that style by removing as many of the speed bumps as possible. I honestly don’t see what value those speed bumps add (even when minimized), other than seeing who has which files “checked out”, which can never be 100% accurate due to offline checkouts.
Brian’s email:
Edit-merge-commit is a model that we want to support and will some day. Unfortunately we were not able to get it implemented for V1. I don’t know what to tell you there. I’m always interested to hear from people who prefer edit-merge-commit. It seems to having explicit checkouts is better (if you can mitigate the costs and deal with the offline issue). We haven’t done everything in V1 yet to make the checkout model we have great (unfortunately). We have plans in V2 to make checkouts work while you are off line and to make it asynchronous. This way it should be transparent and appear as if you are using edit-merge-commit but have the advantages of checkouts - including enforcing exclusive checkouts of unmergable files, allowing me to easily see all files that I have modified, and allowing me to inspect files other people are working on. I think when we do this we’ll convert many people to checkouts but only time will tell.
I wish I had a better answer for you right now but I don’t 
Brian