I think this may have been addressed in a recent release, but projects involve far more than just the development team; Design, project management, video/photography, client, SEO, etc. will all need to be using the system as well. Beyond that, a project starts long before development is even thought about. Most of those teams will be doing work, that needs to be tracked, well before we're ready to create a code repo. With the way things are (or were), code is front and center and half the team doesn't care about that at all. There are also projects that have no development at all from the other teams (video/photo shoots, SEO for customers we didn't build sites for, etc.)
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.