In theory, by now we should all know the first line of the Agile manifesto. So why do so many seemingly intelligent developers insist on the process/tool-heavy solution of branches and pull-requests for internal work on their teams? And is it the wrong, and potentially highly damaging, solution to a more important and probably undiscussed problem?
One time in a dev meeting I saw someone stand up and say they have "a radical suggestion". This turned out to be "let's completely disable commits to master" and pile on the restrictions and rules in GitHub (to me this is radical reactionary, not radical progressive). Yet we hadn't identified any recent problem caused by commits made to master or the absence of restrictions.
Implementing sweeping strategies in the absence of identified problems is rarely a good idea, and people often get this backwards, proposing a solution then telling you the kinds of problems they think it solves. What is the problem being solved by using branches and PRs (process & tools) instead of trunk-based development and pairing (people & interactions)?
"People can break the build by pushing to master without running the tests first" - is the problem here that people could break the build? Or is it the lack of trust in other devs to act with professional discipline? To me the latter issue is much bigger. If there isn't trust and discipline within a team, then that team is unlikely to be highly effective and may even slide into dysfunctionality.
If the problem is a lack of discipline, enforcing a rigorous process to contain it is unlikely to build discipline. Trust and empowerment typically bring out the best in people - give them responsibility and they will step up. It feels good to be trusted, and good will spreads. A team with a high trust level is likely to be a team with a good team spirit.
A good team is also always pulling in the same direction, and continuous integration - not just pushing completed features to master, but every last well-crafted commit, and equally frequently pulling in other changes - gives that a tremendous boost. It facilitates coordination and helps build shared knowledge of what is happening (don't just pull the changes - look at them, but with an eye to understanding rather than bestowing your approval) - in terms not just of features but of coding style and patterns.
However the problem might not be a lack of discipline - it might be a pure (or even impure) absence of trust. The introduction of controlling processes is often a way of consolidating power structures or building them from scratch for later (ab)use - and I would always question people's motives in these cases. In such highly bureaucratic hierarchies, those on the lower levels often feel absolved of responsibility and that is not likely to end well, either.
(Another reason I have seen to introduce restrictions on source control is the containment of a toxic employee - there is little to be said on this; the solution should be to ditch that employee)
Some may choose to do this in response to a team with a high ratio of junior developers. Again, this is an approach which is unlikely to foster rapid improvement and engagement in the juniors. A culture of collaboration with pairing and mobbing will be more effective in both upskilling and building rapport. In my experience junior developers tend to be highly conscientious when you give them trust, and probably less likely to blithely break something than a confident senior.
Finally, it could just be done blind - the received wisdom is to use this strategy and so it gets implemented without question. This kind of trap is easily fallen into by the best of teams with the best of intentions, though ideally a good team should have a sound reason for every decision made whether it's process or technology.
Whichever way, building a process into a team which signifies a lack of trust is unlikely to ever improve matters and instead may simply cause more problems (and the stilted pace of branch / PR / review / merge is, to me, a problem in itself); instead look at the real problems being faced and see how they could be solved in a more collaborative, and indeed simpler way.