You're basically asking "what's the best way to write commercial software", and if you ask 5 guys you'll get 8 answers.
Therefore, the best answer I can give to such a broad question (not sure it's "overly broad" and thus a candidate for closure, and thus I will try to answer) is:
It depends on how many developers are working together. In a smaller development environment, say in a medium-sized business that insources a lot of custom app development, there may be a lot of projects that need to get done and very few programmers to do them. In that case the IT manager usually hands each project to one, maybe two developers and say "get this done, do as good a job as you can but I need it in a month". This is usually a pretty free-flowing environment in which self-starting "lone wolf" programmers can thrive. However, in such an environment there tends to be a lot of competing frameworks brought in independently of each other by developers who don't sit down and talk about unified structure. Code quality can suffer, and code often doesn't adhere to any one "manual of style" other than maybe what's defaulted by the IDE.
On the other hand, code houses generally organize into teams, throwing as many people as the schedule and budget for the project call for. These teams require not only self-starters, but good team players who communicate with each other and collaborate. This provides the "synergy" that managers love to talk about, increasing velocity. But, that requires the entire team to be humming along like a well-oiled machine, and to have a project manager that is good at keeping the development roadmap free of obstacles.
It depends on how many projects need to be developed concurrently. Generally it's a good idea to keep one team working on one thing until they're done, then reevaluate the team's size and makeup before assigning the next big thing. Keeping a team doing one thing keeps them focused. However, the more people per team, the fewer teams you have, all other things being equal. That increases the velocity of the team on one thing but may decrease overall throughput. Incorporating work items from other projects into the schedule for a team gets the small things done but takes the focus off the main project, causing a reduction in velocity caused by mental gear-shifting. Small teams reduce velocity but increase the number of concurrent "pipelines", reducing time that items sit in the backlog with other department heads going "why haven't you started work on my project?".
It depends on the scope and budget of projects. If a client needs one developer to augment a site that their in-house UX guy has wireframed, and they need it in a month for $10 grand, and all those constraints are feasible, there's no point in assigning an entire dev team to it; it's not what the client ask for, what they need, nor what they are willing to pay for. Conversely, having a one-dev team work on the next in-house superproject is not a really good idea if you can help it; not only will development be slowed because only one guy's coding it, you're only getting one developer's perspective on the solution which is by its nature going to be a limited one.