This is an excellent point and something we are thinking a lot about. From a design point of you, we need a way to share and maintain multiple design files across a distributed team. This is something we are actively working to solve for ourselves within GitLab.
From a project management point of view, we need to be able to see all the issue the team is working on along with what is in the pipeline. Multiple assignees is just one step in our process to giving users a holistic view to the entire project.
You can currently see an overview of issues and MRs assigned to you (as well as your GitLab TODOs).
* Repo access
You can narrow repo access to a certain group (i.e. make it internal) see [1]
* Group-level issue boards
We have an open issue for cross-project (group-level) issue boards, see [2]
* Multiple repos per project
We discussed opting for a non-repo-centric approach to projects in [3] Check out the discussion in there, to see our reasoning for sticking with one repo per project.
* Non code projects
You can disable the repository in a project, so you can focus on just the issues, or you can have a repository with only graphics.
We use both internally. Our organization project doesn't have a repository [4], and our marketing repo has lots of design stuff [5]
[1] - https://docs.gitlab.com/ee/user/permissions.html
[2] - https://gitlab.com/gitlab-org/gitlab-ee/issues/928
[3] - https://gitlab.com/gitlab-org/gitlab-ee/issues/1295
[4] - https://gitlab.com/gitlab-com/organization/issues
[5] - https://gitlab.com/gitlab-com/marketing/tree/master/design
You can only have one code base per repo, too. So our PM may go in and create a project for an app and then when we go to develop, realize we need two separate projects. Or maybe they will go create a new project for a new version of an existing site, but we will still be using the same codebase. It makes sense from their view point to track it separately and with a clean slate while from a code standpoint, it makes absolutely no sense.
Beyond that, I personally have 74 tickets assigned to me across a dozen or so projects. PMs are tracking tickets in dozens of projects simultaneously. The last time I looked, there was no good way of seeing an overview of everything like that.
Organizing by client while also ensuring that all users have access to all repos without allowing public access to the repo is also a pain.
If we were only a development company, we'd use it for sure. But GitLab is too tied to the code to be a complete project management tool. There's also the issue that we want to have our CRM in the same place (it currently isn't) and there is no way GitLab will ever offer that.