Number of PR's means very little with overall productivity. It's a vanity metric.
Anecdata: It took me 4 weeks to write a 250 net new lines of code line PR. Normally, I'll write about 1k lines of code per week. I ended up having a tasks that significantly changed security models and required a lot of small, distributed changes.
There are many reasons PRs can be large.
Often it's indicative of broader issues e.g. lack of automated testing, inadequate CI/CD processes, incomplete business requirements etc.
I made 400 last year. It was two fixes across many files owned by many different teams.
Ideally it would have been two. Sometimes playing the politics game is required.
Are those actually the upstream repositories, though? And is it known how they interact with them?
Google has Copybara [1], which allows portions of a monorepo to live outside as an entirely separate repository without the need for things like Git submodules. It supports synchronization of histories, pull requests, path and file transformations, etc.
In that sense, something like Copybara would allow them to, relatively, easily open source those bits, receive outside commits, and then sync the changes back to the monorepo.