Is a build server really necessary?

Before .Net when our applications (COM, MFC, etc...) needed to be compiled and deployed I always insisted on making sure on the following process:

1) The developers checked in all source code (VSS, Perforce, whatever source control system you prefer).

2) The person responsible for the build would  then get the latest source from source control and attempt to compile it.

3) The resulting binaries would then be deployed to QA, and the same build image would then be deployed to Production (whatever that means: a web farm, a master CD, etc...).

The above process has a few advantages:

1) All code is properly checked in (there are no "forgotten" classes, files, etc... lost when the developer's hard drive crashes).  In many cases, if a file is forgotten, the project won't compile

2) Any third party dependencies are immediately indentified.  For example, if the developer installed a third party OCX on his/her environment the project won't compile on the build server.

3) All compiled binaries created on the build server are "clean" (for example for linked libraries, the correct DLL would be used, and not some strange DLL installed on the developer's system).

Now, with .Net, whatever code is being compiled is really ending up as IL.  So for companies with smaller 2-3 development teams, where some developers are also responsible for deploying the apps, does it still make sense to go through a build server.

I understand there are still benefits (1 and 2 above), but if we find other ways to make sure code and dependencies are checked in or documented, would it be ok to bypass the build server all together?

What do folks do at Microsoft?  Anyone has any strong feelings either way?