Maybe I wasn't clear in the article; I'm not suggesting that JSP as such is dumped, I'm suggesting that an alternative to using JSP as a way to create JSF views is added to the specification in the next round.
JSP by itself is great, but the semantics between JSP and JSF clash, so the combination is far from ideal. Unfortunately, because of these semantics differences, I don't see how JSF, nor JSP, can be amended to work well together.
As an analogy, take a bicycle and a car. They both serve the purpose of taking you from one point to another, but in two very different ways. You wouldn't even think about using a bicycle and a car at the same time.
JSP and JSF also both serve the same purpose; dynamically generate a web app user interface. But they do it in so very different ways that using both at the same time just doesn't work very well, and it can't be fixed by changing either one of them.
So, why not admit that mixing JSP and JSF was a mistake, keep JSP support in the JSF spec for backwards compatibility, but focus on a finding a much better way to declaratively compose a JSF component tree, optionally bound to static content for parts of the user interface, for the next spec rev?
What's great with JSF is that its core API allows us to start exerimenting with this now, so we can provide our real life experience with such alternatives as input to the next rev of the spec.