hokomoko might actually be the most qualified to answer this in our community, as he was and believe still is a Spring engine developer.
I'll try my best though. In the video encoding whole state of a given frame is immediately visible and has no hidden parts. That's why you can take any frame and encode following ones incrementally/differentially.
Not the case with Spring/ZK. Some state is indeed capturable: unit, projectiles, wrecks, explosions, terrain, positions, rotations, etc. can be captured and theoretically restored. On the other hand engine has a huge blackbox called Lua Virtual Machine, which has its own state, coroutines, variables, arrays, etc. Almost everything in ZK uses Lua and amount of state is huge. Even if it's possible to capture, I don't think it's possible to inject it back without appropriate support from widgets and gadgets.
It's interesting to note, that current save/load code does exactly this: every gadget is responsible to save and load the state manually by themselves. We are unable to save 100% of ingame Lua state this way, but what we are able to save/load at the moment I think is good enough. Now imagine if we distribute a copy of the savegame to every player and ask them to load it, the game will start in a state, very close to what it was when the save was recorded. That said, load() requires engine reload, which is not convenient, and savegame distribution/coordinated load infrastructure is not there and wasn't even thought of. Moreover, if it's even possible to do, the effort is quite huge and the immediate profit is not clear.
All ^^^ IMO. Might be wrong in every sentence.
