I don’t know how to argue for weaker code reviews, but I know to argue that code reviews aren’t being done properly.
Code reviews serve multiple purposes, skipping them simply because of time is silly. Don’t argue for that.
Code reviews are conversations, every comment should be responded to, otherwise you aren’t really having a conversation. There can be various types of comments in a code review: suggested changes, praise, request for clarification about either the code or the business rules, even questioning whether a particular approach or tool was considered.
How one responds is an entirely separate issue. It’s not necessary and it absolutely should not be required, that the response is to change the code.
Assuming these comments are about request for changes, just changing the code is wrong, changing it with an “Ok” is marginally acceptable. Agreeing with the comment and making the suggested change is great. Agreeing while explaining that because of REASON you won’t make the change is ok. Disagreeing because of REASON and saying you don’t want to make the change should be fine. Disagreeing with proof that the suggestion doesn’t work is great.
Who approves a pull request is an organizational process issue, there’s no developmental reason it has to be done by anyone in particular. Likewise there’s no developmental reason why it can’t be done by a specific person.
In short, I think you need to focus on the fact that a reviewer says-so is insufficient reason to make a change, it has to be a convincing argument. And then push, not for the right to skip the review, but that it be given a higher priority. Doing reviews should be considered part of the job, if someone isn’t giving their input, that should be considered the equivalent of refusing to write code.