The author seems to have a bit of an unreasonable animosity to that technique, from this article and others of theirs. It seems to me they could have written m

The author seems to have a bit of an unreasonable animosity to that technique, from this article and others of theirs. It seems to me they could have written much the same article the other way round: starting with a rename-based method, observing that the naive implementation isn't good enough, and going through the steps you need to make it robust in practice. Then they could have put a naive undo log in their "one weird trick" section and claimed it doesn't work. I think the best rule of thumb is that if your outputs depend only on your inputs, you should aim for some kind of rewrite and atomic replace. If your outputs depend on both new inputs and the previous state, you need the database-like techniques.