Evan,
This is a tough one. It's right up there with "What size server do I need?"
The best advice I know to give you is to think of the application from the outside in. Do you have multiple applications that will be using the same services? Will they all be using the exact same symbology for all layers? In most cases, this will dictate what you want to do with your services. You may find that your best solution is to group some data into multi-layer services, while leaving others as services unto themselves.
My personal experience is that what you want to do with the data layer dictates where it should reside. If these are static data services that don't change a whole lot, like hydrography or elevation, it might make sense to keep them in a single service and use them as-is, with the symbology you have defined in the map document. Likewise, if you will be doing most of the app-specific stuff client-side with Feature Layers, it makes sense to put them all in a single service. Feature Layers can access individual layers in a service and display them as a single layer on the client. You can also define the renderer for the layer client-side and override what's in the map document.
If you're doing something very service-specific like editing, then you would obviously want a single service for that data.
A general rule is that whatever is easy on the server will cause a bit more work on the client, and whatever is easy on the client might take a little more work on the server. If you group all your layers into a single service, then you might have to do some work setting up Feature Layers on the client to get exactly what you want. Likewise, if you break all your layers out into singleton services, hosting those on the server takes more resources. Using them on the client side is super simple though, you just add the services you want and the rendering and functionality is all defined for you.
I hope this helps. Without having a knowledge of what you need the applications to do with the data, it's a hard question to answer.
Jeff
