For me it’s mostly about interoperability with other tools. CLI tools (grep, df, sed, pandoc etc.), Emacs, org-mode, filesystem browsers, and so many others.
I get that tags are a more flexible way to organize notes (and they work on block level too). But namespace hierarchy has value too. And the logseq page namespace is 100% isomorphic to the filesystem; so unless the devs saving the filesystem hierarchy for some other use I don’t see why not use it. Why build a hierarchical namespace in the app and ignore the beautiful fast filesystem underneath it? You might as well put it all in a database.
I grew up with hierarchical filesystems; they’re in my blood and in my fingers. I stopped putting all my files in one folder in the '80s. So yeah, I guess it just irks me that logseq doesn’t take advantage of this feature of all modern OSes, and builds it itself. Seems like wasted effort at best, and source of new bugs at worst (like now they’re going to switch from %2F to __ because %2F is “ugly” – wouldn’t an actual filesystem be more elegant?
Anyway, one of the devs responded that this is a core design decision and won’t be revisited. (See Proposal: Changing How Namespaces Function in Logseq - #22 by alex0 “Our vision is to separate namespace structure from the limited tree structure of file system.”) So I guess this is not going to be pursued. 
4 Likes