It's a hashchain. They predate blockchains. I used them a long time as just signed, text files full of hashes. Trusted Timestamping used them. Blockchains were a highly-wasteful modification of hashchains for a different purpose. Databases, logs, and hashchains are still better for most things. Centralized services with decentralized checking of a signed log is still more efficient since centralized tech is itself more efficient.
A blockchain is a modification of a hash chain to make it usable in cases where different transactions conflict with each other. In the case of TLS certificate transparency, Go packages, etc., a log entry "This object with this hash was published" does not conflict with a log entry "That object with that hash was published." You can append them to the chain in either order and it's fine. For a financial ledger, "This money was moved from A to B" conflicts with "This money was moved from A to C," and so one needs to be applied first so that the other can be rejected. If both transactions are signed it doesn't matter which one (for the correctness of the system, at least), but all users have to come to consensus about which of the two is accepted. Otherwise you have the "double-spend" problem.
Bitcoin's blockchain solves this problem with "proof-of-work," i.e., making it computationally difficult to add another entry to the hash chain. Because it's difficult, it's unlikely that both transactions will be accepted at the same time, which serves as a publicly-verifiable way to arbitrarily pick one. There is a small financial incentive for the network entity that successfully solved the computational problem, hopefully offsetting their expense in "mining" the "block." (As a further means of making sure only one is accepted, even if both are mined in quick succession, it's common practice in Bitcoin to wait for a few more blocks to be mined before B or C accept the transaction, which forces the network to accept one chain or the other.)
Satoshi's innovation was that proof-of-work can be used to allow arbitrary / anonymous entities to participate in this system without risking someone creating several thousand anonymous entities voting in their favor, or creating one view of the hash chain for B and another for C to convince them both to accept the transaction. (Satoshi's innovation was not the append-only cryptographically-verifiable store; that's just a hash chain. It was securing updates to that store without a central trusted coordinator.)
There are other ways to arbitrarily pick one transaction or the other, e.g., using a distributed consensus algorithm and admitting participants based on "proof of stake." Or you can redefine the problem to allow double-spend to a limited extent and make A responsible for paying out both B and C - this is roughly Stellar's approach.
But if you don't have a double-spend problem (or if you have a central trusted coordinator), you just need a boring old hash chain, which can be implemented much more efficiently - and possibly expanded to a hash tree, as described in this article.
This is different from a blockchain because it's more efficient - the length of a log proof is O(log(N)) instead O(N). A blockchain in the Bitcoin sense does not satisfy properties 1, 2, and 3 in this article.
The term "blockchain" is ill-defined (and often is used to mean just "Merkle tree"), but in the sense of the 2008 Nakamoto paper, a blockchain derives its security from having more computational power participate in the security of the system than the unused and available computational power in the world, and specifically from having financial incentives (mining) to make this be the case. In other words, the data structure is specifically about money and corruption, by design.
Basically yes - if your application needs neither currency nor privacy (e.g., signing Go packages), linking it to a data structure that inherently deals with both would be a mistake. Currency and privacy are both difficult, so avoid bringing in dependencies on them if you don't need them.
(Again, the Bitcoin paper is specific in how the data structure is only secure because the consensus algorithm creates financial incentives that hopefully outweigh the incentive to misbehave. If you drop that from a blockchain, it isn't secure any more.)
It's an argument for being cautious about handling money and avoiding it if you can. Of course, Internet commerce deals with it a lot, but sometimes it's an unnecessary dependency and removing it simplifies the problem.
