YFaces encourages you to focus your work on the special use-cases of your project. From your frontend perspective many use-cases can be modeled as a widget or component. YFaces supports this by providing an easy (or more complex...as preferred) concept. The simplest case is just a component class linked with a human readable View. (View is changeable without a redeploy and styleable by a designer)
Simply components that are reflecting a special business case like edit a customer, display a cart etc.
Yes and no. Existing technologies are used and combined in a usefull manner. JSF is used as component layer, Facelets as Viewlayer and Spring for a flexible but optional runtime configuration. YFaces hides JSF complexity and improves many ideas behind Facelets. Many features won't work with just combining those two libraries.
Because available components are only just functional and very basic. For your use-cases they are a good toolset but not more. Practically more disadvantages occur when increasing the number of external component libraries. These are: More complexity: JSF itself is a complex world. Each additional library increases this as it brings new concepts and models. Less compatibility: Many libraries are shipped with various filters or own View- and Navigationhandlers. Using one library works well but special combinations with others can lead into instabilities or other strange behaviour.
Compared to JSF the viewconcept is much more powerful. Plain xhtml files can be read and styled by any designer. View changes are applied without a redeploy.
Comparing to Facelets the improvements can be found more in detail: Each view is backed by a component class whose scope is bound to that view. A xsd file gets generated for each view; this adds code completion for your components to your IDE. Each view gets automatically registered during startup as component Tag. Each component tag allows dynamic passing of attributes whose values are injected into the component.