This question seems subjective, but I'll try to approach this answer objectively.
The Chef Server provides a publishing system and search index with a RESTful API.
This means you can:
Distribute cookbooks for nodes through a single location that has an API, and primitives for creating version constraints, retrieval, all the things you'd probably expect out of a publishing system.
Store data (attributes) about nodes you're managing. Whether it is one or one thousand, you can get information about the nodes directly through the API. You can also use it to tell nodes to run different recipes.
Store arbitrary information about your infrastructure in what Opscode calls "data bags." This is any information you like, such as user information, application information, or anything else you can think of about your infrastructure.
Query the server for information about nodes, "what are the webservers in production?"
How does this differ from Chef Solo? Glad you asked!
With Chef Solo, you have to get the cookbooks, node attributes, data bags, etc, to the nodes yourself. This means publishing them somewhere that multiple nodes can get them, or rsync/scp a repository over to each node that is managed. There is no centralized store of the node data, and no search index for any of it.
In the beginning, it's all very small, and easy to distribute. Between 1, 3 or even 5 nodes this often isn't a problem. But then most folks find themselves with some problems.
- "It sure would be nice to have a way to upload the cookbooks to the nodes easier"
- "Man, every time we update a cookbook, production goes down because we didn't want that change done there"
- "How can we gather all the node data in one place and query it?"
The list goes on. What happens is that many people don't want to "run a chef server" so they build their own on top of git repos, http servers and the like.
The use case you're talking about (approximately 5 nodes) is the target for Opscode Hosted Chef's "5 node free" plan, then you don't have to manage a special system to be your Chef Server, at least to see if it's something that will work for your infrastructure. You can then continue to grow into larger paid plans, or move your data (easily through the API) to your own Chef Server in the future.