>>> (1) How many project areas should we have?
In general you should organize a RM project area so that your team delivers multiple releases over time from these artifacts. The project area provides the authorization boundaries: who can see the artifacts and who can create and change them. Within a project area you can use team areas to provide finer-grained permissions.

Here are some additional considerations:

• fewer project areas == less administration. Visibility of artifacts to a wider group of people (which could be good or bad depending on your organizational culture and corporate requirements).
  
• If you expect to grow to many millions of artifacts you need to start thinking about issues of scale (and perhaps partition into multiple project areas)
• Within RM project areas you have more expressive options for link types -- you can define your own link types.  At this point, across projects you have pre-defined link types available.

>>>(2) How do I ensure that we can handover Project documentation to System owner as permanent documentation in a way where I do not loose all my traceability. 

You could use module baselines (aka snapshots) to reflect the state of the module at a particular time. Since the scope is the module, the system does not guarantee that the artifact at the other end of the link (design, test case) is the same as when the module baseline was created.  You need to create baselines/snapshots in those tools too.  Some people create PDF docs for archival purpose to simplify future use of this information.  If you haven't already done so, you might want to customize the document generation templates with the "studio" included in Rational Publishing Engine (RPE).

>>>(3) How do I in a project link to an artifact in the permanent doc base. e.g. a Uses relation to existing functionality? 

You could store the archival PDFs in your RRC project and define your own link type to express the relationship to them.

>>>(4) How do I check out permanent documentation to at project when I need to extend existing functionality?

You can consider the latest artifacts in the system as the "head" of a stream, so these are the ones you would modify.  Alternatively you could create a copy (emulating a branch) for a new project.

Note that we have work underway that will significantly simplify your use cases. You might find this post informative:  https://jazz.net/forum/questions/135495/the-basic-concept-of-rrc