I agree with you this is a problem but I don't think the problem is that there are no comments. I think the problem is that the pull requests are instantly approved. That means no one is critically reviewing your code. And if they aren't reviewing your code, they probably aren't reviewing each others' code either. You aren't learning / improving, and bad code is landing in the main branch.
What you need here is allies. Figure out who on this team does take code review seriously. Put code review on the agenda of your next team meeting and talk it out. If the majority sides with you, more likely you win. If not, then even at most start-ups, there is some management. Get them to understand that this "buddy approval" issue is very real and a threat. Show them examples of instant approval or even of obviously bad code that was not caught.
With majority or management backing, go to whoever administers the repository and ensure that rules are put in place on the code repositories that require at least one trusted reviewer (who takes code review seriously) to approve any pull request before it is merged. All the other "buddy approvals" therefore carry less importance. However, I think it is still important that those who don't take code review seriously still be required to do it, in the hopes they improve.
I have battled this very issue on my team and having trusted reviewers was my solution. You have to protect the repository from habitual "buddy approvers". In my experience, if you can't make that happen, there is probably no way you can win the code quality battle. The best you will be able to do in that case is cover your own backside and wait for the inevitable disaster that forces the issue. Don't be the one holding the bag when it happens. Don't compromise your own code review discipline; maybe some of it will even rub off on them. Don't merge your own pull requests until you have more than the required number of approvals. And make sure you write better and more comprehensive unit tests than the next guy.
If you can do this without even the appearance of casting blame, then the next time a glaring defect that should have been caught in code review makes it into the main branch (ie code with bad anti-patterns), bring it up with the whole team as an opportunity to improve quality with a renewed focus on the code review process. Just make sure there is no blame, or you only hurt your own reputation.
Specifically concerning the need for comments, I think comments should generally only be made if you see a problem or have a question. If the PR is good, there is no reason to comment; just approve it. However, if a PR is declined without any comments, I think that would be a problem because the contributor does not know what should be changed to make the PR acceptable.
(And, this question probably belongs in Software Engineering SE.)