The Killzone MP rendering choices look like they aligned with this (maybe because of similar performance demands or early testing??), which in retrospect may have been informed by the constraints and choices made for the engine for KZ3's stereoscopic mode.
While reprojection between two frames for 60 FPS wouldn't be temporal, the engine could be structured so that the renderer just sees it as a choice in which buffer it reads from.
I think the data could be segregated into tiers. Given the complexity of materials these days and environmental inputs, there would be data references and calculations that are not affected by the left/right offset, those that are not significantly affected, and then those that might need to be done per-frame. Even the latter case might be interesting if the calculations or reads have a relationship that allows them to be recalculated based on the known relative position of the cameras. A merging of the phases might allow for better cache and fixed-function utilization.
We'd have a phase composed of all the work that could be done once per frame pair, and possibly a further subdivision for data that might be usable for some kind of temporal reprojection to reduce the work for the next frame pair.
Then there'd be data that the engine might be able to reproject from one eye to the other.
Then there'd be the highly variable stuff in a third phase, although if there are tweaks to the architecture like Sony's desire to use compute as an input to the front end, some of the submission work could be reused or recalculated on the fly.
The area I'm curious about is primitive setup and fragment coverage, particularly if tessellation gets involved. The details for whether the setup pipeline can be used to provide fragment data for two different viewports at the same time, or the other frame can be extrapolated from the results escape me.
GCN's behavior under tessellation is the one area where hitting the stereoscopic 2x worst-case would be a good result.