I did some research about this issue and I found out that, as you said, the restore view phase is the only point where this is mentioned in the spec. However I agree that this should happen earlier (before the before-PhaseListeners of restore view are executed).
Furthermore I think it is sufficient to do a viewHandler.initView(facesContext); somewhere in LifecycleImpl.execute() before the phases are executed, so we do not need the code on FacesServlet.
The problem is that the spec dictates that this has to be the very first thing that happens in the restore view phase, but (implicitly) after the before-PhaseListeners where executed:
Spec section 2.2.1: "The JSF implementation must perform the following tasks during the Restore View phase of the request processing lifecycle: Call initView() on the ViewHandler. This will set the character encoding properly for this request. ....."
Spec section 7.5.1: "The initView() method must be called as the first method in the implementation of the Restore View Phase of the request processing lifecycle, immediately after checking for the existence of the FacesContext parameter...."
I also tried to move the call to initView() from RestoreViewExecutor to LifecycleImpl and the demo worked fine, however 4 tests in RestoreViewExecutorTest failed, because they expected the call to viewHandler.initView() in the RestoreViewExecutor.
In addition I also did some black box tests of Mojarra and you are right, they don't do that on Restore View, but somewhere earlier. I guess this is yet another undocumented spec-change. I recommend that you create a spec issue for this and when we get response from the EG, we can move the code to LifecycleImpl to solve this issue.