In theory you can keep some pages shared between people in a subfolder of the graph and use something to sync only that folder. Eventually to avoid conflicts (for example someone else create a page that already exist in the private portion of your graph) you can agree on using a specific namespace for all the pages shared in the team, like [[Team Foo/Page bar]].
I haven’t tried this with other people, if someone manage to do so let me know, especially if using Git 
One thing to note with the journal-centric approach is all the backlinks to a particular tag from various dates in the journal view automatically builds a chronology of blocks referring to the tag. This is very powerful and I use it both at work and home.
Working on tasks or projects etc, I put everything into the journal and I get a timeline with events, meetings, and whatever you put in. And with no cognitive load of having to look up and decide where this and that needs to go.
Just wanted to chime in here and mention that after 2+ years of using logseq I’ve abandoned using the journal pages directly, because I choose to sync my graph with git, and I found using the journal with a distributed git workflow leads to large merge conflicts between different environments’ Logseq instances creating the same conflicting day page.
As a result, each place I use logseq, I have a different logfile (for example, [[Personal/Log/2023/11/26]], [[Work/Log/2023/11/26]] that opens up the page with a tag for that day. That way I can go to the day in the journal and see all the log entries for that day from each environment, but avoid the merge conflicts on syncing.
Cool write up! I think I explored most of those things a little bit almost immediate, because I’ve worked on knowledge-management type projects before, so have the concepts in mind.
This seems like a software limitation more than a conceptual choice. See e.g. Separate page title from file name - the title:: property should change the displayed name and not the namespace/filename. (personally I’d also love it if the / namespacing used subdirectories on disk, but oh well)
I think a better argument for using page-tags (or better general page-properties) is that it allows for multiple hierarchies, which can be extremely useful. For example: apple could be fruit/apple, but it could also be ingredient/apple - both are referring to the same type of thing, but in different context/taxonomies.
Of course, there’s not much build-in functionality for using page tags like this (unlike the namespace hierarchy feature), but you can do a lot with queries. Some discussion of multiple-hierarchy tools over here too: Generate explicit hierarchy out of properties
@Luhmann: This is a really helpful post. Also, I wanted to let you know that I posted a link to your equally helpful PKM comparison chart on the Reddit sub r/PKMS. If you want me to remove it, I’ll do so, of course. I’m referring to you chart on your luhmann-logseq.notion.site.