There's a similar flow diagram in a 2017 paper titled "Do you need a Blockchain?"  which identifies 3 types of blockchain:
* Permissionless Blockchain
* Public Permissioned Blockchain
* Private Permissioned Blockchain
Also, https://eprint.iacr.org/2017/375.pdf Section 4.4.2
^ Detailed analyses that explain why blockchain is an appropriate solution
But please do elaborate how they are "known to be worse." By whom and can you cite the analysis that proved so? Certainly not known by Google if they invested in a blockchain-based storage solution?
>well understood tradeoffs
That's definitely not the case if you take the time to read any blockchain-related thread on HN. But, please, feel free to tell me what are better solutions for the cases I mentioned.
I think this paper  made a decent case for permissioned blockchains (i.e. "where the participants are limited to a predefined set") in cases where one must store state, accommodate multiple writers who do not trust each other and does not have access to an always-online trusted third party. The number of cases where the final condition applies is small, but positive.
> Where could I read more about this?
"If no data needs to be stored, no database is required at all, i.e. a blockchain, as a form of database, is of no use. Similarly, if only one writer exists, a blockchain does not provide additional guarantees and a regular database is better suited, because it provides better performance in terms of throughput and latency. If a trusted third party (TTP) is available, there are two options. First, if the TTP is always online, write operations can be delegated to it and it can function as verifier for state transitions. Second, if the TTP is usually offline, it can function as a certificate authority in the setting of a permissioned blockchain, i.e. where all writers of the system are known. If the writers all mutually trust each other, i.e. they assume that no participant is malicious, a database with shared write access is likely the best solution. If they do not trust each other, using a permissioned blockchain makes sense. Depending on whether public verifiability is required, anyone can be allowed to read the state (public permissioned blockchain) or the set of readers may also be restricted (private permissioned blockchain). If the set of writers is not fixed and known to the participants, as is the case for many cryptocurrencies such as Bitcoin, an [sic] permissionless blockchain is a suitable solution."
Hey, this is relative to your needs obviously. An always online trusted third party could be the arxiv server for papers. Or a consortiuum of industry players that don't trust each other and set up a foundation that runs a central database. Or a central bank. Really depends on the problem domain.
And yes, I have talked to people who have proposed to use block chain for storing papers. So while it might be obvious to you that blockchain is not a solution for that, it's still a good paper that lays out in detail what a blackchain does and doesn't do.