> So, someone deciding whether to use this might consider whether they just want to publish a tamper-evident log, or whether they are publishing something that looks more like a dataset with a temper-evident change history.

The tamper-evident log is useful as an ancillary tool. You can write your keys or perhaps hashed records into the log and then use it later to see if the database has gained unlogged records or has lost logged records. And, if so, where in the sequence the deviation occurs.

I've used dumber versions in the past: hash chain fields on a single table, plus row signature. This approach has the nice property that it's very general and comes with proofs.