Sort of, but imagine this scenario:

I very rarely have issues in problem space A, but I don't really test for A. Maybe a few here or there but it's a small minority of my tests and the coverage is probably just incidental. I test heavily in problem space B for whatever reason.

I get hit by a bus, and you're my replacement.

You have no experience with problem space A, so there are few if any tests around that space. All of a sudden the coverage is misleading because we might have 100% coverage or close to it, but the thoroughness isn't there and suddenly releases are less reliable and support ticket volumes increase.

Not necessarily. In many firms the turnover rate is significant enough that you have no idea who will be working on your code in six months or so. Unless you are on the sort of team that never changes, you can't really use your past experience as a guide for a future team's strengths/weaknesses.

Sorry, my thoughts stopped short. It does in part.

But the collective mistakes of a team aren't a predictor of potential future members of the team. For example, we started hiring "junior" programmers, which increases the skill gap.

It does if team and their strengths/weaknesses stays the same for the life of the codebase. If it changes, then that property goes away to some degree with missing coverage against someone's weaknesses. Better to have QA cover correctness against whatever would undermine it.