Subversion has a lot of third party support. Vault has just a few things.
Surely where Subversion has 3rd party support, Vault has 1st party support since you have purchased it.In my experience, first hand information (from the makers) tends to be better than 14 forums spread over the world? Though we now have SO so this point may be mute. :)
Subversion has locks as well. I've never needed them, though.
Subversion allows you to mark files as 'must-lock', in that case checkout (lock), checkin (commit with auto unlock) works. AnkhSVN visualizes this just like the VSS Check in check out.
Subversion has:
Subversion will get a more efficient HTTP protocol in 1.6 or 1.7 (Work in progress). This might make it possible to create an IIS plugin.
See the subversion book on branching and merging in Subversion.
SVN has true branching http://svnbook.red-bean.com/en/1.1/ch04.html, branching is just handled differently than most source code control systems.
I use Vault, so I'd like to correct one error in your feature list:
Vault has a VS plugin, but it only works if you're going to run in checkout-mode.
Not true - I'm unsure of which version it was added in, but you can run vault in Edit|Merge|Commit mode in Visual Studio
I would also add that Vault uses MS SQL Server as it's repository - makes backups easy.
The Source gear website has a comparison. However I would suggest neither. If your moving to a new repository you want to be looking at a distributed version control system.
The likes of Monotone, Git and Bazaar have really raised the bar in terms of productivity.
Having used both 'in anger' I'd choose Subversion (with TortoiseSVN) over Vault every day.
When I went from Subversion to Vault this is what I noticed:
Obviously some of this is down to the way that Vault was configured, but you get the idea.
I ended up writing a bunch of scripts to automate the things that Vault couldn't do, but even then there are limitation on what the commandline version can do. Plus the Vault API isn't documented.
I spent several years using (and administering) Subversion at a previous job, and the last three years using Vault at my current job. At this point I'm desperate to get away from Vault and back to Subversion (or potentially a tool like git or Mercurial).
We've had a lot of issues with performance and reliability (Vault doesn't always pick up files that have been modified, and on occasion will insist that you haven't modified a file when you have) but this may come down to the (long) history of our repository and how we handled branching in the past. I'd argue that if it were better designed then none of that should have mattered, but if you're not doing wacky things with it then maybe you won't have the problems we've had.
That said, there are some fundamental design decisions that I can't forgive:
Ultimately, Vault's a much less flexible tool than Subversion is, though that lack of flexibility does mean it can be simpler to use. If you have a team of developers who are accustomed to VSS and you're not going to demand much of your source control tool, Vault's probably a fine choice. Having gotten accustomed to Subversion's flexibility, though, I find using Vault an exercise in frustration.
One feature that Vault has built in that Subversion does not have built in, is Vault can be configured to retain the files modified timestamp. This is a feature I can really benefit from. As a workaround, Subversion does allow configuration to have it set the modified timestamp to the commit time, which is good enough for most of my scenarios. To benefit from this, I have to commit, then delete my working copy, and then do an update, to force the timestamps to be the commit timestamps, so that I can deploy the files and have their timestamps match subversion's timestamps. There are suggestions to use scripts or whatnot to store the modified timestamps in properties, but I don't know if anyone has done this successfully, and if so, I don't know how solid this workaround would be.
There are many tools (bug tracker, continuous integration) that integrate with subversion. In case of vault not many tools have support for it.
Vault does a great job of implementing seamlessly with Visual Studio.
For everything else, it's terrible.
The "WebDAV" support is painfully slow- so slow that I found it quicker to checkout with the Vault Client and then switch back to Dreamweaver rather than try to checkout within Dreamweaver over WebDAV.