Nice seeing you here. If JSP 2.1 proves me wrong, great! Until then, I remain unconvinced.
I don't see how JSP can be modified to remedy the parallel creation and rendering of components for the first request, because processing a JSP page can have side effects and processing the same page twice (once to create the components and once to render) may lead to different results because the page can contain conditional code.
The buffering issues may be possible to fix, either with hacks in the JSF tag handlers or with new hooks in the JSP tag handler API, but either way, it will be a kludge.
I don't see any way to get around the fact that non-JSF tag libraries can't be used without a special set of rules (e.g., required "id" attributes and no non-JSF iteration allowed).
Regarding the analogy, JSP and JSF goes beyond the dashboard and the steering wheel; the differences and overlap are more fundamental, because both have request lifecycles and semantics that simply don't match. Using the features that make JSP so popular (e.g., conditional processing of a page, changing the page flow in a page with forward/redirect) will always clash with JSF, where the same things are intended to be done by other means.
Even if I just don't get it and there is in fact a way to solve all these problems in JSP 2.1, I still think an alternative that completely separates the template from the view specification ala Tapestry has many advantages over the JSP model. So an alternative to JSP is very much an important area for experimentation no matter what, and I'm sure that including such an alternative in the JSF spec would be very welcome.