Re: Doesn't surprise me
This is in fact a normal way of working for Perforce. Let me explain.
Perforce is philosophically derived from the RCS/CVS lineage. RCS operates on single files and just keeps a sequence of revisions to that single file. CVS is kind of a hack around RCS to introduce the weird notions that your project might consist of more than one file and that sometimes you might even want to "branch", i.e. not have a linear progression of versions. However fundamentally things are still tracked at a per-file level.
This makes it fundamentally very easy to check out a subset of the files of your project, since the files are in some sense all quite independent. So you *can* have a single repository which contains all different products of your company.
The reason you will *want* to is because $DEITY help you if you ever want to share some code between projects which are NOT using the same repository. Probably best to merge the projects into a single repository then, so better start with a single repository in the first place.
So not only is Perforce a centralised version control system in that it encourages a single repository per project, it encourages in fact A Single Repository *period*.
In contrast, Git tracks changes on a complete repository basis and doesn't deal with changes to individual files. While doing a partial checkout ("sparse checkout") is possible in Git, it is really not recommended. So Git strongly "encourages" you to split your repository in more manageable parts.