> Because determining an entity’s state becomes an exercise in replaying events, event sourcing requires quite a lot of bookkeeping and technical wizardry in order to work and perform well.
Don't you think that updating records in a database also requires quite a lot of bookkeeping too? I'd say it requires even more bookkeeping, as when you update a record, the previous value is gone forever, unless you explicitly store it somewhere else. Ensuring the data correctness and consistency with state-oriented persistence is very hard. Anyone who has access to the database, can just go there and manipulate the data, leaving no trace of why it happened and who did the change (again, if you don't explicitly enable the database audit log, and then spend hours or days finding a record in the log).
Concerning "technical wizardry", won't you need it too when dealing with relational or SQL databases? Sophisticated ORM frameworks like Hibernate don't exist without a reason and they consist of hundreds of thousands lines of code also for a reason. Dealing with impedance mismatch is hard, especially with relational databases, which seem to dominate the world of application state persistence nowadays. Event Sourcing eliminates impedance mismatch entirely, and only for that benefit one might already decide using the pattern.
The whole "magic" in recovering the entity state is one line: S' = S + E. Of course, applying events to an entity state requires code, however it makes state transitions very explicit and easy to reason about.
I would add that limiting the benefits of Event Sourcing to audit log only is quite shortsighted. There are lots of, maybe not that obvious, additional benefits, some of them I mentioned. But there are more. For those tho have read this article and decided never to look at Event Sourcing again, I'd urge - read some more. Watch some videos, where people who build and run event-sourced systems in production share their experience and go beyond hello world and playing around.