This is exactly it. When I worked in a ~10 person team I just didn't get it, PRs worked quite well (with some basic discipline, they're not perfect). When I moved to a... much larger company... I don't know how PRs would work here, it would be way too unwieldy. The Gerrit style works fantastically here.

Well are we talking about commits pre- or post-merge? I don’t care how many commits you put into the PR / MR as long as they squash down to a single commit upon merge.

it lets you maintain version history when working, then most workflows auto squash on merge

IMHO equating commits and PRs puts undue pressure on the scope and quality of a given commit, adding potential for unnecessary stress and eliminating the benefits of an additional buffer / layer for aggregation of changes. A PR representing a sizable feature or refactor might naturally contain a dozen commits, each dedicated to a logical area or a requisite subset of the whole. Assuming on principle a goal of keeping main in a known-good state, such intermediate and incomplete changes (fine in an unstable feature branch) would wreak havoc.

It's equivalent to asking, "Why would you have more than one story in an epic (or task in a story)?".