Hm. Sounds like it would get kinda inefficient to understand the current state of an element that's undergone a lot of changes, but I imagine that could be easily solved by caching the current state and only referring to the history when you really need to.
I can definitely see its utility for making a time-travel roguelike like you're making, since it means you can unroll the activity back in time. I had an idea for a heist-planning roguelike a while back that would let you "scrub" forward and backward in time to let you let one character do their thing, then go back and define what another character does simultaneously, but what I ran up against was how to handle things when those two characters would interact; it would "void" things after. But if you just have a list of "things they're going to try to do" instead of trying to save the state at each time point, the characters could adjust, I think. This sort of idea would really assist with that!
Cool, looking forward to checking out your game.