It completely depends on what they call "a change", and the article does not make that clear.

If they're doing some sort of strict continuous integration, then, a "change" could be a 25 lines function with a 100 lines of unit tests, in the frame of a large project where the function will be used later in a UI component that will only be merged in two weeks.

The fact that it's "deployed" does not mean it's "used" in production as a final thing ; it might very much be "a step in the development".

And, even if they're shipping "feature" (that is, they're deploying the last commit in a project), it does not mean that all millions of users are seeing the change (they could use feature toggles, A/B testing, etc...)

Seen this way, about 2 PRs per day per eng is not unreasonable, and with enough devs, you can reach it.

Finally, they might very well have some automated PRs (i18n, etc..)

Not every PR is a feature. There will be lots of laying groundwork. Stuff going in but not yet activated as a feature flag. Small changes often make roll back easier. Regressions easier to detect. You can blue green your little change and auto detect if it is causing latency or availability issues on 1% then 10% etc. of traffic. This means you can early detect and do easy roll backs as nothing much has changed.

Downside: your code is always a Frankenstein monster of feature flags that need to be cleared up! But hey that's more PRs to boast about.