What you are stating is true when you’re using vintage JSF 1.0/1.1 API with “pure” JSF components. There was no builtin component with which you can represent a HTML <div> element (so that you can accomplish the general page layout on a semantic manner). Also, embedding “plain” HTML in a JSF page was a pain because it got rendered outside and before the JSF component tree. You have to put plain HTML in <f:verbatim> tags over all place. The purists and the unawareness are less or more forced to use <h:panelGrid> (which renders a <table>) to position the elements in the page.
Apart from that, during the early JSF ages, Netbeans shipped with a builtin visual JSF editor which enables you drag’n’drop and bind JSF components visually without the need to write any line of code. This obviously generates a lot of at first sight unnecessary and unmaintainable code and the pixel-precise positioning of the elements were “behind the scenes” achieved with a <h:panelGrid>. Those kind of JSF applications are in view of maintainability and web semanticity a complete disaster.
Most of the negative stories you’ll hear about JSF with regard to front end development is related to this. Most of the JSF users/observers/ranters from then are currently still blindly focusing on this because of the bad experience they had and/or they think that JSF is nowadays still the same and/or they see the visual editor as part of JSF while it’s “just” another (bad) tool. Also most of the ones who says “JSF sucks” are usually ones who started using it with a visual / drag’n’drop editor without having any solid background knowledge of what’s happening under the hoods (especially Servlet API!).
Since JSF 1.2 (which is already over 4 years ago released btw), the <h:panelGroup> component got an extra attribute: layout="block" which will let it (finally) render a fullworthy HTML <div> element so that you can bring a more semantic layout using JSF components only. But it’s not only that, JSF 1.2 also comes with an improved view handler which enables embedding plain HTML in line among other JSF components without hassling with <f:verbatim> tags. You could nicely put <div> elements around where you want without adding more verbosity.
Even though this was a major improvement, there were still two other major (however not directly UI related) problems with the standard JSF implementation: 1) state management among requests is hard without grabbing the session scope (think of preserving the same data in tables and dropdowns and the conditions of e.g. rendered attribute); 2) everything goes through POST and you can’t nicely invoke JSFish actions through GET.
Since JSF 2.0, which is almost already 1 year old, those problems were covered with a new scope, the view scope, and a new set of components for GET actions. Plus, JSP is replaced by Facelets as default view technology. Facelets greatly eases templating and creating composite components without having to resort with raw Java code and/or custom components/renderers. Even though it’s XHTML based, it can perfectly render a HTML5 valid respone with just <!DOCTYPE html>. The XHTML is just there because Facelets is under the hoods using a XML based tool to generate the (X)HTML output. The XHTML based templating does in no way imply that it can only emit XHTML/XML.
All with all, your markup concerns are a non-issue when you’re using JSF 1.2 or newer and also XHTML (Facelets) shouldn’t be an issue since it can perfectly render HTML5 valid markup.