JSF was designed in part by the authors of Struts to create a "Struts" that did a more accurate implementation of MVC (Struts is technically "Model 2") and to get rid of all the interface and subclass dependencies. The idea being that POJOS are more re-usable and easier to unit-test offline than framework-dependent code. Which is why I chant endlessly:
The more JSF-specific code that is in your JSF webapp, the more likely it is that you're doing it wrong.
The other thing that the Struts folks didn't like about Struts was that you had to define too many classes for each component. In JSF, you define a view template file, a backing bean (model), and that's basically it. There's no separate "action" class to transition data in and out of the MVC part of the webapp, just POJO methods that are defined in the same class as the POJO model.
My gut feeling is that Struts can probably process faster on heavier workloads, but I have no stats to confirm or deny. JSF is much better when you are primarily working with data entry forms, as it automatically populates the forms, validates the forms, reports invalid data without requiring user-written code, and propagates the form data (View control values) to the backing bean (Model) when (and
only when) all form values are valid.
Neither Struts nor JSF are "greedy" frameworks that require total ownership of the application. You can mix Struts and JSF and regular servlets/JSPs with impunity, and in fact, when you are attempting to output non-form content such as PDFs,
Word documents or spreadsheets, it is far better to avoid cramming them through JSF and use a straight
servlet to generate those types of data.
As for the job market, locally I see about a 50/50 split between Struts and JSF right now. A lot of the Struts stuff is older apps. You may see different demands depending on where you are located.