I’ve said it before, and I’ll say it again:
It’s because “blockchain” software is a thing that already exists, but its superclass, “distributed log of signed proofs” software, isn’t a thing that already exists (except in the form of the subclass, blockchain software.)
There are tons of use-cases for which a “distributed log of signed proofs” is the perfect fit. Have you got an architecture where nodes independently make “stuff” and want to publish it “somewhere” for other nodes to find — where the other nodes have some independent criterion they can apply to validate published “stuff” to decide whether to accept or ignore it for their own use? For example, have you got a sharded data warehouse, where each shard is publishing its own write-ahead log segments for replicas of that shard to use? Well, add a “distributed log of signed proofs”, and now your closed data warehouse becomes an open network where anyone can have their own “shard”, and anyone can choose to replicate from a “shard” they trust.
(Yes, DHTs and/or gossip networks are sort of like this — but neither provides durability or linearization. If you want a new node to be able to look up historical “stuff” from publisher-nodes that aren’t online any more, then you need durability; and if you want your “stuff” validation algorithm to — at least within a sliding window — reject duplicate “stuff” from the log, then you need linearization.)
It just so happens that all the software that exists, that offers the “distributed log of signed proofs” guarantee, also offers the additional guarantee of all the nodes doing the validation of proofs serially, reducing over each new proof against an accumulator of an existing global consensus state, to build a new global consensus state, where proofs can only be valid relative to a specific “base” global consensus state. We call such proofs-relative-to-a-state “blocks”, and we call the resulting system “a blockchain.”
Most of these use-cases don’t need that additional guarantee. It doesn’t get them anything, and it costs a lot (e.g. in the inability to concurrently validate proofs; in the requirement to keep a forever-growing durable representation of global consensus state around on disk; etc.)
But the people building these systems are generally practical engineers, who “buy” blockchain software (and just ignore the features they don’t need), rather than attempting to “build” their own “distributed log of signed proofs” software with no known antecedent.