Question about org-mode archiving. Pros for standard, "flat" method of archiving (vs. mimicking entire tree structure)?

I'm curious about archiving workflow. Flat vs. Trees. The original designers of the default system must have had a pretty good idea of why they did it that way. What was their intended workflow? In most posts that I see about this, a person that's usually fairly new to org-mode will lament org-mode's default flat-ish method of archiving, in which the original parent tree context is set as a property. Then discussion about how to do it that way, either through a function or through project management (only archive once the project is closed out), separate files per project, etc. What I'd like to know is who among you prefers the default flat-ish method for archiving, and how does that work for you? How do you resolve the typical objections to that method, which drives people to seek out a tree-mimicking approach?

I don't care how things are archived as long as they are: if the text I need is present somewhere and I can find it with `isearch` I'm a happy camper. You ask: > How do you resolve the typical objections to that method? I'm not aware of any objections, could you give an example or two?

Archiving have a reason: performance. To keep current org files quick to open and navigate. The most generic form of archival is by date (like yearly rotation) another is mirroring current structure with a date prefix like "afile.org" > "afile-YYYY.orgarchive" but in the end all it count is still being able to access information without "retrieving issues" or "performance issues". Honestly IMVHO files and structures does not count that much "for archiving" because they depend on how you have structured you files headings. The rest is more a matter of ripgrep then else...

One big one is time tracking. I have long running projects with subtasks and I want to be able to track how long pieces of the work take. When a task is done I also want to archive it to not clutter my view of incomplete work. Once archived, however, all context is sort of lost such as tags and parent tasks. I know tags can be saved as properties, even inherited tags, but thats not very helpful as the standard clock reporting mechanisms do not use it.