I've actually seen this in practice, someone wanted their code merged before they would even consider working on the issues pointed out in the code review because they didn't want to waste their time on fixing up the code without an ironclad guarantee that it would be merged. The devs didn't want to merge a "code bomb" and then either have to scramble fix it themselves or yank it out when release time came around so the whole thing just turned into a time sink for everyone involved.
Sounds like an edge case scenario (eg not normal).
If the project had a demonstrable history of merging things though, then it sounds like the person wanting the gatekeepers to accept the not-up-to-standard code first was just being egotistical. :/
I've hit similar issues with new engineers in my closed-source product.
It's more than an egotistical thing; some engineers just don't understand how to write good code. The engineers who treat code review feedback as optional don't last very long.
A code review for a newcomer is not a formality; it is often rather burdensome for all parties until the newcomer is familiar with less obvious parts of the code.
