You're assuming it is not an old bug and that the branch is somehow kept around for other developers to re-open months or years later.
A PR for each commit seems overkill. Usually a PR is for a feature, but code-wise, a feature might require several atomic changes. For example: prepare configuration, move files around, add tests, add new code, delete old code, refactor. Each of those could be a separate commit, bringing you to a polished feature with test coverage.
Might depend on how companies use git but I just verified I can see commits for PRs from 2017 in my work codebase; could bisect that if needed (although code likely is no longer relevant.)
I think splitting PRs into multiple commits can make sense when there are only 2-3 commits but you're right that it doesn't when there are more than that.
A PR for each commit seems overkill. Usually a PR is for a feature, but code-wise, a feature might require several atomic changes. For example: prepare configuration, move files around, add tests, add new code, delete old code, refactor. Each of those could be a separate commit, bringing you to a polished feature with test coverage.