I would say at this time unless you need 64Bit specific assemblies built you are best staying on a 32bit operating system. This will happily build MSIL .NET assemblies which I guess for most of us is the bulk of our work. OK you loose a bit of performance if you have 64bit hardware (or virtual hardware in our case), but I doubt this will be critical, shaving a few seconds of an automated build is not normally important.
My main reason for saying this is what as you extend your build process you will no doubt started to use community developed build activities, some of these seem to get a bit confused if you are on a 64bit OS. The issue seems to be that they cannot easily find the TFS Client assemblies in C:Program File (x86) as opposed to C:Program File. For example we have a build that automatically updates version numbers and deploys via ClickOnce; it works fine on a 32bit W2k8 build server, but on an identically configured 64bt W2K8 build server it gives the error:
error MSB4018: The “MSBuild.Community.Tasks.Tfs.TfsVersion” task failed unexpectedly.
error MSB4018: System.IO.FileNotFoundException: Could not load file or assembly ‘file:///C:Program FilesMicrosoft Visual Studio 9.0Common7IDEPrivateAssembliesMicrosoft.TeamFoundation.Client.dll’ or one of its dependencies. The system cannot find the file specified.
So what appears to be just a simple path issue, that is probably fixable in an XML configuration file or with search paths – but is it worth the effort? I would say not in general. I want to keep my installation as near default as possible, which I can with 32bit.