I should have mentioned that it is good to have separate team areas for the projects if you use just one project area, because this would allow you to also separate concerns in planning per project. If you don't all the work items of all projects would be presented on one plan, even if you have separate categories for each project.

stuffing projects into one project area and managing the project by using team areas does improve upon the administration and even reporting for the projects.

But at some point , isn't there a limit to how many team areas (projects) you can stuff into one project area before performance degradation hits?

and when it does hit what are the options available for improving upon that poor or unacceptable performance ? 

I know of one organization that brought me in to consult on their CLM practices ,  ad this is teh route they took. one project area is servicing over 200 projects using team areas for each one.  The performance is terrible and as a result not many new users or new  pm's are using the implementation.  I notice also it is well ver 30k in # workitems already.

how would you address the problems of this type of deployment ?
any literature or postings or content that deal with these issues and how to address them ?

There is no one-size-fits-all approach and there probably never will be.
I am not aware of limits for the number of team areas you can have, but obviously at some point you will have issues with usability. For example, general search for work items on work items page, too many categories etc. I don't think the performance should suffer, as all work items are stored in the same DB anyway. So 30K work items are 30K work items even if they are distributed across project areas. I don't know the DB layer so I don't know if I am missing something here.

With respect to performance I would suggest JazzMon and monitor the system to understand where the limitations are.

It is easy enough to split the teams across several project areas using process sharing. So it would make sense to have more than one project area and distribute the teams across those instead of keeping all in one.

The key phrase here is "simple project".   In particular, if you don't need any of the features described in Ralph's answer, then you don't have to create a team area.   So one approach is to just use the project area as your team area initially, and then when you encounter the need to have a team area, create one and move the team members from the project area down to the team area.

Geoffrey, please see my comment above ?  any ideas?

You will probably want to start a separate question on your performance/scalability issues, since it is unlikely to be caused by using team areas vs. project areas.  In particular, you'll want to identify specifically which operations are performing poorly.  A performance problem that might be associated with using team areas instead of project areas is that some lists in the GUI can be against every object in the project area (independent of team area boundaries) such as streams and build engines.   But there usually are filters you can apply (such as "only show me objects of that kind in team areas I belong to").