I find it is always best to keep reviews minimal, and any review comments should generally be "this isn't ideal - consider doing it this other way next time - but LGTM".

Sure, the end result is a less perfect codebase. But considering code isn't the end goal - a working product with happy users is the end goal - imperfect code can be the right way to achieve that.

And besides, all code that is still in production in 5 years is probably due a rewrite anyway - now that the company has pivoted a few times, the product has evolved, and the use cases aren't what they originally were. The computing landscape will also have evolved (eg. new language versions, new library versions, new hardware with different strengths and weaknesses, etc)

There's a balance here, and for me it comes down to whether or not I'll be able to remember all of the narrow edge cases that this particular piece of code will introduce.

Will braces around if statements matter when QA comes back with a regression 4 weeks from now or when Product has a new feature request? Probably not, so a "LGTM with a nit" is warranted.

Adding a json request body to this GET request? Yeah, I'll have to remember that little bit of quirkiness, and quite frankly if the team member is adding bodies to GETs, I can't rely on them to remember that quirk or solve anything after that. So while that is technically a "style choice" since it does work, that's a blocked PR until Requested Changes are made.

We must work in vastly different businesses. In five years, my company will still be selling similar products to the same customers — likely the same product’s successor model, and the code we write today may very well be the maintained legacy code then. To me, your approach sounds like hell because it means each line of that imperfect code will have caused a bug and/or forced a refactor commit.