The bullet points you describe in your question are all either ways to measure code quality or support processes. While they do attempt to verify that your code meets a particular quality standard and provide some organizational tools, they don't actually produce good quality code. Sensible software development practices do that.
Let's take your bullets in turn:
Unit testing
The purpose of unit testing is to validate method functionality, provide some test automation, allow refactoring to proceed without breaking existing code, and to encourage good design. You and I both believe that it's a good practice, but there are coders who can produce good code without unit tests. How do you tell those folks that they now have to do it your way?
Testing coverage
Mostly a red herring, having a high degree of testing coverage is widely believed to demonstrate and prove that your code works, when the reality is that simplifying your code so that you need less test coverage is probably a better practice.
Code Review
How many shops actually take the time to do this? I have yet to work in one.
Having any Merge/Pull Requests
Git workflow is a scene all unto itself. Git is a Swiss Army knife with 30 gadgets, when most shops probably only need 5. Do you need a sensible Git workflow? Absolutely. Does it involve Pull Requests? Not necessarily. If you are a project owner on Github, then you'll deal with Pull Requests. But if you're part of an internal team, I don't see how Pull Requests are relevant.
Using separate branches for features
This has some merit, but merging can be a very difficult process, and unless you're very disciplined, staying out of the main branch until your done with your feature (and then resolving the inevitable conflicts when you merge your branch back into the main trunk) can become a nightmare.
What should block code merges/accepting pull requests
It should probably build. Beyond that, you have to decide how much top-level authority you need. Does a team leader review all requests before commit? Again, I've never work in a shop that required this.
So what is the point?
The point is that these processes are all ceremony. None of them have anything to do with code quality, except insofar as they provide checks and balances to whatever effective coding practices are already in place to produce high-quality code.
