I doubt installing the SQL2005 beta side-by-side with SQL 2000 is an issue (if it actually installed as an upgrade to SQL 2000, that could be an issue, but I didn’t realize it would even allow you to do so). As I said before, some perf issues with prc_get were found and fixed since the CTP shipped, so that’s almost certainly what’s raining on your parade. I can’t get you updated bits, but I believe there will be another CTP release in the not-too-distant future.
Our branching story is more like perforce than VSS. When you branch, by default it will create the branched items in your workspace (which means you’d pay the per-file copy cost at least as far as your client’s filesystem is concerned). However, the server side operation is (logically) a link operation at branch time, and you can choose not to create the branched items in your workspace at branch time if the local filesystem cost is a problem (from the command line, you’d specify the /noget option; in the VS UI, there’s a checkbox from the branch dialog).
As far as support for SQL2000 and VS2003 goes, it all comes down to what Team System needs (not just the raw Version Control feature set). Team System depends on features new to Visual Studio 2005; there’s no practical way to make it “plug in” to VS2003. I’m not sure if the version control components themselves depend on SQL2005 or not, but I know several features of Team System (including the reporting features relating to version control) do depend on new features in SQL 2005. So, while I’m sure there is a marketing angle to the version dependancies, there are definitely technical reasons as well.
I hope that covers your questions and concerns (and is of some interest to other readers). As always, feedback and/or additional questions are welcome.