Welcome to the JavaRanch, Adrian!
If those are the worst problems you have, congratulations!
The basic rules regarding
JSF backing/managed beans are the same as for any
J2EE app, since the JSF scopes are based on the J2EE scopes. There are a few "gotchas", but not many.
Request Scope is (almost) Completely Useless - I capitalized that because it's one of my fundamental rules of JSF. JSF is primarily about maintaining a stateful conversation between a form (web page) and the server, and the transitory nature of request scope means that state cannot be preserved over the lifetime of the conversation. So unless you really know what you're doing, avoid it.
Session Scope is the most common way to maintain extended state. There's no such concept as "too many" beans regardless of scope - the beans are collected in hash-mapped dictionaries so the main constraint is RAM. Having lots of big beans x lots of users = Need More Memory. That's one of the reasons why JSF added View Scope. View Scope is simply Session Scope, but the object is automatically deleted when you navigate to the next View instead of leaving your webapp littered with unused objects or requiring manual brute-force removal of outdated beans.
Another alternative is Flash Scope, but I find Flash Scope to be rather contrived and limited. I mostly use it for passing error information forward from one View to another.
Then there's Application scope, which is handy for keeping shared objects such as menu SelectItem collections.
And finally, there's the custom scope where you have to do the management of the beans yourself. That one isn't very common. As of JSF 2.0, it was awkward in both design and use and not especially well-documented.
Beans can (frequently should) initialize themselves via injected data (Managed Properties). If you are initializing beans based on parameters coming in from the View, that's not only less secure, it's probably less performant. The idealized JSF application keeps its data in the server and passes it around within the server, using Views only to present and edit specific properties. Generally, I'd keep a User Profile bean in Session scope and inject it into whatever beans needed it.
And no, there's no exclusivity requirement for classes, If you want to use the same class as a basis for multiple beans - even in different scopes - that's OK. You obviously would need to give the instances different names in order to keep them separate, but the total number of instances has no limit.
Which brings up a common point of confusion. A lot of people tend to think that the View Model (backing bean) for a JSF app must also be the Data Model (ORM entity) of their persistent data. That's not true. If you're using an ORM and the data model object isn't a good fit for the View, create a separate View Model object so that the MVC part of the app can operate optimally, Then when MVC hands over to business logic (the action method), the business logic can deal with the translation from UI Model to persistent Model. The actual relationships between the 2 models is up tou you. It can be as simple as a decorator façade, an aggregate, or even full-on translations and computations.
