The most important thing to keep in mind is that code quality is dependent on the criteria you are measuring against.
In a vacuum, essentially every piece of code can be improved. If you have no standard to measure against, you can run the risk of either falling into a bottomless pit of optimization, or at best ending up disagreeing with team members over what counts as "good enough."
In business, software is usually a means to an end. It exists to fulfill some sort of business need or facilitate a business process. The software does not exist to be perfect, it exists to solve a problem. The standard that matters is usually "good enough" to solve the problem at hand. Of course, there are subtle implications around performance, quality, and maintainability, which it sounds like is where your concern lies. These gray areas are why standards matter.
Where does that leave you? What should you do to address your problem? I would suggest the following steps:
- Determine if there are standards in your development team, in terms of code quality, performance, or maintainability. If there are, make sure your reviews follow them. Do not suggest things that aren't mentioned or enforced, or you may run the risk of "wasting time" on changes that aren't seen as important.
- If you disagree with the standards, or they are not complete, address that issue directly - don't try to enforce your own ideas through rogue reviews.
- If there are no standards, discuss the specific reviews where you and your coworker(s) disagreed with whomever is approving the new code (i.e. your team lead). Ask them how they make decisions on approving these merges. Treat their decision making process as the standard against which you should conduct code reviews.
If you've done all that and there are still running into issues, consider the following:
- In your code reviews, reference the standards you are measuring against. It's easy to take code reviews as personal criticism. You can avoid that trap by keeping it about the code, and not about the people or the skills those people have (or don't have).
- Have a casual chat with your coworkers. Approach it as a learning experience for you - not them. Ask them to walk you through their approach and why they made certain decisions. You may find that you end up understanding why they did something, instead of feeling like you need to correct them. Or, you may find that by asking them to explain something out loud, it becomes obvious to them that they need to make a correction (and you may not even have to be the one that points that out.) Sometimes, when someone is asked to explain their own work, it helps them see the problems in it.
- Have a chat with your management. Explain that you're worried about how code reviews are being interpreted. Again, don't approach this discussion as if you have the answers and you're trying to correct someone else - approach it as "here's a problem, how can we proceed?"