If I offer my customers a source of ordered records, the "trust" in that system is the fact that they pay me to make sure records are ordered. If I sell a fast or slow log database, approximately zero customers in the world care to verify ordering cryptographically.
Or by "blockchain" do you just mean .... records with sequential IDs? Because sequential, guaranteed IDs surface gappiness/idempotency a lot easier than Markov chains over cryptographic primitives.
That also doesn't address the other core problems in the article: the replication (or data retrieval/polling) protocol is a lot more complex than a blockchain's "I can verify and replicate the entire chain state from the beginning of time to you" single behavior. People want more specificity than that.
Especially since in most of the cases where it's not-totally-insane to use, the right solution is the classic distributed database which came first, where the ledger is among predefined/controlled node-membership... as opposed to a bloated mass of workarounds-upon-workarounds to make it survive being ungovernable.
I've seen some boosters pivot to saying "private blockchain", but that's a vapid marketing-lie, a contradiction like selling "single-user Twitter" when really it's just a blog.