100% fair point!
And just to clarify, I was thinking about making a contrib module to experiment with this, not a core module. Something that could be installed on @graffte and @pat’s instances as early as this week. Nothing would preclude migrating from a document asset to a different entity type in the future once that is settled (although care should be taken by anyone experimenting with it to be aware that not everything might be transferable).
On the point of “first class entities” (which was also mentioned in the thread on “Farm Assets”: Interest in a new Farm asset type?) I think a good question to ask is also: what features of assets DO we want on the new entity type? In many cases, we may find that a lot of the asset entity features are in fact desirable. So it’s worth doing a comparative analysis along those lines too…
For example:
- Do Documents need to be marked as active/archive? Yes.
- Do Documents need to have an Owner? Maybe?
- Do Documents need to have flags applied to them like “Needs Review”, “Priority”, etc? Seems useful!
- Do Documents need to have location and be moved around? Sure, if you are using them to track physical documents.
- Do Documents need to be grouped, and to change group? I don’t see why not?
- Do Documents need inventory? Probably not.
- ID tags? Probably not either… but maybe useful.
The benefit of using the existing asset type is consistency and we get all that other stuff for free. Plus we don’t need to maintain another entity type.
Also worth noting: in farmOS v1 “Areas” were not assets, because they seemed like they needed to be their own thing, but over time more and more overlap of requirements with assets became clear, so we made them into asset types in v2. So if it seems like I’m too often championing the “everthing’s an asset!” idea, some of it is historical. 
Not disagreeing at all that we should give it more thought before adding something to core! Also not opposed to experimenting with trivial solutions in contrib to feel out where the pluses and minuses are.