My take is the key point is review the new commits on develop/main branch prior to decide doing a merge or rebase. There is no silver bullet that solves all the situations.

• If the either their changes or your changes are small and unrelated to each others codes (eg. someone has a big feature, and you are only changing variables names, or vice versus), I would do a rebase to accept coworkers changes.
• If the changes are related to your work, I would do a merge and interact with merge conflicts and use our brain to decide which line to keep and which to edit, better yet talk to the coworker and come to a consensus before submitting the PR.

When the git framework is catching conflicts and initiate human-human interactions or discussions, the git is working properly as expected, git is a tool to help human work together effective.