Dude, I'm the lead developer and maintainer of an OSS project with roughly 120 kLoC in Scala, and I probably break the build more often than not. (Of course commits don't make it into master until they're green.) In fact, I'm typically surprised when a PR passes the CI on the first try! There are way too many configurations to test locally (a PR triggers around 10 hours*CPU of tests on our CI servers), so I only test a single config before submitting a PR. Uncovering the impact on the other configs is left to the CI servers.
Interesting that this is something of interest and research since anyone who does active development in Open Source could have given the answer without it.
The majority of PRs tend to not affect the build status.
The rare cases (4-5%) where it does, is a complex architectural reason, or the tests are variable. Which doesn't even factor into this research... Such as tests that rely on timestamps/external requests/etc that randomly fail, yet are still a part of the test suite (pretty common).
The places where people are afraid to contribute generally tend to have overly complex contribution guidelines, rules, and acceptance criterion where you must sign a waiver, agree to their code of conduct, submit some form of a RFC... rather than the CI.
So yeah, I'm not surprised by those results.