Say, something went wrong in your app and as a result, a user gets blocked for abuse but that user claims to not have done anything to break rules. Now you can go back to your staging environment and play the events leading up to the block in that system and see what happens first hand.
What’s needed for this is a comprehensive log of events for basically any interaction that happens around your app and a staging system to replay events to. Based on the sensitivity of your data you may want to anonymize some details before hand but that’s about it.
IMO, event sourcing has a real benefit when we are asking for "why" was there this state rather than "what" was the state.
My application is designed following CQRS principle, but I don't use Event Sourcing yet.
If my application is really focus on the "what" rather than the "why" (since operations are really simple, meaning there are no different ways to end up the same result), is it similar to use the Temporal Pattern as introduced here (persisting object's versions/revisions in database) rather than implementing event sourcing?
Especially for tracking user abuses (like posting some insults) that were temporary (so hidden), a simple query asking for the version where the abuse was commit could be enough and quickly made, rather than having a "script" in staging environment replaying the events to get the right snapshot showing the abuse.