i second Ralph's inputs.  the primary question is if the other teams also follow the same process?  if yes, you could create individual team areas under the one larger umbrella called project area. 

also to consider are what kind of actions the teams perform and how they would like to visualize their data and go about the daily activities.  the dashboards, reports might have to be created accordingly

from futuristic aspects, the user load and especially the concurrent users might be a big question to answer.  if your teams are small a common project area should suffice and if you expect to have bigger teams, separate project areas will be useful for administration and maintenance.  you might want to refer to the sizing guide which gives very good idea about the performance based on the different load conditions. 

I think an answer in the forum in this, without knowing more and talk about things is probably impossible.

There is no right or wrong, there are only tradeoffs. For example it is hard to change the decision later. It is probably easier to move data into another project (split) then moving from several to one. Both approaches will require a lot of manual work, for example moving work items from one project to another.

In general you will need streams and components for all the teams for the different applications. The more applications the more you have of these. You will need timelines for teams with different release cycles. All users in this project area will see these. You can change ownership and visibility on streams to limit visibility.
In general all work item customization will be common, including enumeration values etc. At some point it might become too much information. You could probably "split" projects then, but, as already mentioned, that is a manual process (move work items).

The issue of splitting is always the tradeoff of saving administrative overhead versus how "agile" teams/projects are in terms of administration of their process.

How to split projects in RTC needs some considerations. The basic questions from off the top of my head are:

• Do you need different processes,especially different work item types and attributes?
• Do you need to restrict access to artifacts such as work items?

If you answer one of the two with yes, you should look into having separate project areas. If not, then you could probably get away with having more than one project area. You could use Teams within the project area instead.

In general, separate project areas are needed for separate processes so far.

Another consideration would be, are the projects working on the same general thing? If they do, I would not split along the lines of business unit, but rather on the line of what they work on.