That's the ultimate question. Why should we be using this kind of tools at all? For most of us it is a common tool, but there are developers and software companies that are still untouched by this "phenomena".
I remember what were the reasons when the thought for a build server first came up in my former employment. There was a hardcore rogue developer there (actually not just one of those) who over the years gain too much control over key company software. He never used any version control software, he never cooperated with anyone else, he never followed any best practice. Nobody but him was able to read and understand his code. But still he got the job done, so management was happy until the work overgrown him and the workflow problems became visible. I suppose this is pretty common story in companies that grow from a small poorly managed teams into something bigger and then they find out how hard it is to change, what was supposed to be done right from the start.
The reason for a build server is obvious then. Both management and other developers (not counting the rogue of course, he protested :) agreed it was necessary to extract as much competences from this developer as possible without actually hurting the build quality. Reasoning is this: If it builds on his machine, it must build on another machine, right?
This is called build neutrality and is an essential feature of build automation.
By the time we've been considering implementing a build server, we've already been using a subversion for many of our projects, so it was not such a big move in thinking as if we haven't been.
The thought of automation somewhat crystallized by itself. If the build is to be done on the server, if it shall be done from the subversion, why not run it by itself on a regular basis? Now we are talking about something that just takes a new version of everything in svn, meaning all company projects with all of their dependencies that no one knows anymore, placing them to specific location on C drive, because that's what the build tool expects them to be and building them the precise way the rogue developer did. Difference here is that it can happen in regular, automated manner and it can include other projects of other people. Not just the rogue's.
Even on this primitive stage you can see first signs of continuous integration, meaning taking people's inputs and integrating them together on regular basis. It's there even if nobody realizes that yet.
The important thing that comes along (or better that precedes) implementing a build server is the change in business processes according to software releases. More on that some other time, but basically whoever works with the release doesn't go for it to the developer guy, but takes it from the build server. Build servers often offers features to support this processes. Sometimes don't. But the main requirement here is always supported. That is build availability. When the rogue is sick and support guy needs a release to write to the cd, then there is a problem, because no one can find it in the mess of his files. Build server sorts releases into understandable folder tree that everyone can easily find.
Good story end then?
It seems there are only positives, right? Actually there are setbacks as well. The biggest one I mentioned is the need to change business processes. The change in a medium-small company is always painful when it involves learning, change in thinking and most importantly replacing what's somewhat working as it is by something that may introduce problems. Even if many understood build automation was a necessary step, some saw it only as a complication and it involved emotion. Enthusiasm on one hand and rejection on the other hand.
After some talks and research, we've settled on night build done by cruisecontrol.net. We've modified and reconfigured it many times after.