Sounds like you have a culture problem. You can always open a PR and then discuss it in person or over chat. If your teammates take weeks to review your work, then your manager needs to step in. If nothing changes, then the culture is broken or you need to take a hint. Maybe your 50 file PR is too big and too complex to approach.
I think PRs work best when it’s mostly a sanity check and rubber stamp for those you trust on small changes. But big changes or unfamiliar colleagues get a bit more scrutiny. Checking in code works best at regular intervals. Combined with good tests, checking in code does r have to be a hassle.
Record keeping for the most part. You need something to attach the CI jobs to and PRs are a good choice. There are plenty of cases were a deep review should be preformed. Always presenting that opportunity is good instead of having to do something different from the submitters point of view.
CI jobs trigger on the change, not the PR creation, so there's no need for the extra step. There's no need for a PR for trivial stuff. In the context of teams "internal to a company who know and trust each other", when deep review is still important, is the PR process useful, or is it busywork? Why not have the deep review happen during the development, rather than after?
I think PRs work best when it’s mostly a sanity check and rubber stamp for those you trust on small changes. But big changes or unfamiliar colleagues get a bit more scrutiny. Checking in code works best at regular intervals. Combined with good tests, checking in code does r have to be a hassle.