I did have a 6 month contract with a fairly tight team back in 2019, and it was definitely overall a positive experience. Mix of experience levels, and they were growing perhaps a bit too fast, but there was enough balance and communication. Most people were on site, which did, I think, help out some. I know "remote only 100%" is everyone's favorite 'go to' mode (mine too) but there's some extra discipline and rigor the whole org needs to have to function smoothly to get the best out of a mostly or fully remote workforce.
I know that "my" team members look at PRs as more of a safety net for oopsies than evidence of lack of trust between team members. We allow self approval of PRs so that if/when someone is the only developer working they can still push code if needed.
When I started in the project we did not use PRs and we all agree that they have made the code better and that they have unified our coding style (the fact that Visual Studio/ReSharper auto-formats changed code also helps with that aspect).
This is interesting as a counterpoint to trusting, but it’s funny, I’ve never thought about PRs in either of those terms, not within a team or company anyway. The Pull Request can also be about the code writer asking for review, asking the question ‘is this generally the right way to go?’ The funny thing about projecting ‘trust’ and ‘verification’ onto the process is that PRs simply do not prevent all or even most accidents, automated builds and tests are better at that. PRs can help steer things in the right direction, and they’re good as one of many tools for mentoring people about code they’re unfamiliar with. But PRs can also be used as the opposite of verification: if the reviewer is responsible for verification then PRs can be a CYA where the reviewer is implicated in a mistake along with the writer.