In this specific case, the fucking moron in question was the one who designed the code review process and hired the other engineers, and it took place a significant length of time before my involvement.

Which, yes, does raise interesting questions about how someone who can't be trusted to handle errors in an API call ended up in a senior enough position to do that.

There's a disincentive to actively block PRs if you don't want your coworkers to think you are a bad colleague / not on their side. So you often see suboptimal code making its way to production. This has a worse effect the more terrible engineers there are.

Except in this case it's clearly affecting at minimum the rest of OP's team.

At that point it's not one person being obnoxious and never approving their team members diffs and more of a team effort to do so.

But at minimum if you have a culture of trying to improve your codebase you'll inevitably set up tests, ci/cd with checks, etc. before any code can be deployed. Which should really take any weight of responsibility out of any one member of the team. Whether trying to put out code or reject said code.

Turning this into an incentive that everyone values is a signal that a team has a great culture.