TL;DR; Event sourcing is amazing when only you want to track the state changes of an application, and in order to do that, you have to do some extra work, try to keep your stack simple, ask your self twice and trice before adopting it.
As Martin define how its working:
The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself.
Click here for his full article explaining what is event sourcing, the scope of this article is not intended for explaining that.
Having event sourcing is more complex to manage and store compared to not using it, instead of simply overriding your application values if changes, you have to:
So, I would say only use it when you really need it
It depends on the case you are trying to solve, even CQRS and event sourcing are playing well together and you will see a lot of frameworks provide both CQRS and eventsourcing together but it is not necessary to couple them.
In the end, I have seen a lot of misusage of event sourcing, the misusage cost tech teams time and frustration try to take mindful decicion before adopting event sourcing