Assuming infinite bandwidth and rendering speed:
It sounds like, for a connection of latency L, at time T-2L, the server sends to the client multiple fully rendered frames, each representing the render state for time T for every possible user input that could occur between T-2L and T. The client receives these frames at time T-L, while sending a user input state at T-L which the server will use for a future packs of images. At time T, the client chooses the frame to display based on the actual input the user performed at time T, discarding the rest, and the server receives the user's input from time T-L, using it to render and send the next pack of images for time T+2L.
So while it is strictly true that latency is impossible to avoid for the first two rendered frames, that's only a small fraction of a second and only at the very beginning. After that it's eliminated. Now obviously, rendering speed and bandwidth change the equation and is probably why there is a limit to the latency it can correct for. But this does appear to be a cure for interframe latency.
It's lazy tree culling of every render state at every point in time for every conceivable user input state at that time. It's certainly a big tree, but it seems they are making the statement that it's small enough to fit in modern bandwidth capacities.
Of course, you wouldn't be able to use this in your fighting game example to counteract the relative slow speed of the LCD, but that is because there would be no way to cull the set of images at the LCD itself.