When researching user flows for complex information sharing, I've always been able to validate the need for flexibility in allowing users to group their data in a way that's most relevant to them, and for setting permissions for accessing the different groupings.
So I would advocate for allowing "multiple groups within a category"
You can even look to Slack as a good analogy. Slack started off offering Teams and within each Team: Channels. In early 2017 they introduced, after much user feedback, message threads within a channel. Each of these tiers allow for users to keep information organized and accessible and searchable.
Now, to your questions:
Q1: Do users feel comfortable joining multiple groups for the same category?
If each group in the category has a specific topic of interest, and there's little to no overlap, joining more than one group in a category is not a bad experience. I'm part of a few LinkedIn Groups, and those that are very specific are useful for research - the information is well contained. Now, if groups are essentially the same - e.g., "Houston C# programming", and "Houston C# programming, y'all" then more effort is upon the users to go to different sources for information and aggregate it on their own.
We had this issue within our Slack channels - we'd end up with two channels that were more or less the same topic of conversation (either at the start, or over time) and it got really frustrating and a waste of time. What we did to help clean it up was 1. consolidated like-topics into one channel, and 2. nurtured a culture where everyone monitors the channels they are active in, and if they see unrelated conversations spring up in a channel, help to guide people to the appropriate channel, or if there's some relation - ensure to keep the conversation within a thread.
Q2: What is the benefit of choosing one concept over other?
I'll take one at time... "Categories:Groups":
"1:0" - Works if the posts are all equal to one another in priority and the level of skill-set/interest/discover ability etc. Facebook and Twitter do this with their home feeds - you get everything together. This can be great if you want to know what's going on with your favorite band and your best friend's new project and your favorite sports team - or just want to browse through current activity... but there's a reason why tools like Tweetdeck and HootSuite came about to help users better aggregate topics. Depending on the user - some need more focus.
"1:many" - Allowing different sub-groups/channels within a category will help keep information organized and focused, and it gives the user a better experience for filtering the data most valuable to him/her. And, if there is not a need for many subgroup topics in a category... then one group may be enough. Slack channels and Slack threads are good examples of this - we have some channels with lots of activity and lots of related, but more focused threads, and other channels that get very little, but important activity (Like security patch updates)
Q3: Is there any criteria for choosing the concept?
For this, you need to ask your users. Find out how they will be using your platform, create prototypes and see how they respond with tasks you assign to them during user testing. And always observe what they do to validate the user needs - don't just go with what they say. If prompted something like "Q:How many levels of subgroups would work best for you?" You'll get an answer like "A: oh, minimum 5 and maximum 20" But observe, and you'll find they never create anything more than 2 or threes layers deep.
Hope this gives some perspective.