Working effectively as part of a team is incredibly important for output quality, morale, and retention. My professional experience involving teamwork has primarily been within software engineering, but most of the takeaway lessons aren't limited to engineering.
From the perspective of efficiency, a traditional argument against staffing large teams comes from Frederick Brooks's The Mythical Man-Month. A man-month or person-month refers to the unit of work that one person can accomplish in one month. The basic premise that Brooks argues against is the notion that a software project that takes one person a year to complete (twelve person-months) can have its timeline shortened to a single month simply by staffing the project with a dozen engineers. Upon seeing projects falling behind, many managers want to put schedules back on track by simply adding more engineers to the project.
The problem with this logic -- and the reason it's a myth -- is that each additional engineer added to a project incurs both communication and coordination overhead with everyone else on the team, and so the time to complete a project doesn't actually decrease linearly with increased staffing. This leads to what is commonly known as Brooks's Law, that "adding manpower to a late software project makes it later." 
Because of this line of reasoning, managers or technical leads sometimes over-correct and attempt to maximize efficiency by staffing single-person projects to reduce the communication overhead down to zero. Some companies, like Google, even emphasize in their promotion processes that an engineer has to demonstrate ownership in a project, which incentivizes engineers to define and prioritize individual projects so that they can be the indisputable owners of those projects and increase their chances for a promotion.
The reality is that there are a number of downsides and risks to working alone that affect output quality and morale:
The lower morale from solo projects also tends to mean lower employee happiness and consequently lower retention. For all these reasons, I strongly believe that one-person teams should be avoided in growing organizations and that the minimum team size should be two. In any project, there might be one-person tasks, but grouping those tasks thematically into a shared team context so that people are still working together toward a shared goal rather than working separately mitigates a lot of the above risks.
For companies with many ongoing projects or for products with large surface areas, it's tempting to argue that because there's so much to get done anyways, it makes sense to just staff a number of one-person teams (an oxymoron) on orthogonal projects to make some progress on everything. This can be a symptom that the organization is undisciplined enough to prioritize and either cut or serialize projects. In Crossing the Chasm, Geoffrey Moore argues that one reason many high-tech companies fail to take their product into the mainstream market is due to this lack of discipline in limiting the set of projects to focus on: 
"This isn't rocket science, but it does represent a kind of discipline. And it is here that high-tech management shows itself most lacking. Most high-tech when it comes down to marketing choices, will continue to shy away from making niche commitments... [T]he claim is made that, although niche strategy is generally best, we do have time -- or we cannot afford -- to implement it now. This is a ruse, of course, the true answer being much simpler: We do not have, nor are we willing to adopt, any discipline that would ever require us to stop pursuing any sale any time for any reason."
All of this doesn't mean that working on a team is easy. We've all probably had our share of project experiences where slackers who don't pull their own weight take the fun out of teamwork. But given the above risks, that doesn't mean we shouldn't figure out and practice how to build effective teams.