"In the playoffs you don't tell your star player to stop shooting and pass more" yes, you absolutely do? if the players are making their shots but having a hard time getting open or dealing with defenders then more passing can definitely be the right solution.

If your company isn't budgeting/estimating development effort appropriately, then it's going to affect a lot more things then just code reviews: writing good planning documents, adding tests, Q&A, fixing bugs, design polish, small touches, etc. are all going to suffer if the organization is broken in this way.

Have you considered whether you and your two colleagues are actually the top performers you think you are?

I've argued to management that it's no less than 50% of the time it took to develop. If you're actually reviewing functionality, you need to understand the original ticket, and at least loosely architect it in your mind.

Anything less than that is basically just checking code style or egregious errors.

If your work isn't being adequately acknowledged and appreciated, that's a major culture problem. I've never felt that my code reviews were thankless. In fact, as I've become a more senior developer on the team, I've found that my code reviews or suggestions can sometimes crowd out acknowledgment for more junior members, so I try to redirect praise where appropriate—code reviews are in my mind the most pure expression of pair programming, where you get a collaborative outcome that's better than either the programmer or the reviewer would be able to achieve independently.