most use cases can be effectively handled with less exotic tooling, like a document management system (database in front of the information / documents) or a NoSQL front.

There are plenty of DMSes, none of them do the job well enough at this point.

Blockchains strengths lie in being trustless. For information or document retrieval, it may work at small volumes, but not when it reaches any significant level, even for a small business - compared to a Doc management system or key-value store (NoSQL).

This is why I mentioned "pseudo" blockchain. It doesn't have to be a blockchain, just resemble components of it. No company wants their data immutable.

So, why can't people find "stuff"? They simply don't use a tool and insist they should just be able to throw information any dam where they please.

I don't think you understand the complexity of the problem at scale. We are talking about globally distributed organizations, handling hundreds of millions of documents yearly, localized legal models, external collaboration, multiple repositories, complex user access models and then, automation based on the changing information within the documentation. It isn't simple storage and retrieval.

However, what does work is using a database or key value store similar to what you are using (based on your screenshots) as the "blockchain" of references. Then it doesn't matter where the information is actually stored, as they are all linked to the timeline backbone, including the versions, which at an interface level can appear as a single document.

This allows people to throw information wherever they want and as long as it is appropriately labelled at that point (done automatically or user-defined), it will be allowed to join into the stream.

One place to store and look for any and all types of info, like this showing some of my crypto notes

"One place" just doesn't work at enterprise level for so many reasons. One of them is of course that human data hygiene is terrible. One of the others is just the practicality across quite different tech stack needs based on department usecases.