Even your comment:
> I'd bet people tend to cluster onto the line separating "agreeable and lax" and "rude but firm" (as a sweeping generality).
You are invoking that dichotomy by drawing that line.
Another person:
>Agreeableness in general is negatively correlated with career success.
(Hidden assumption that being "agreeable" means you're not getting the message across).
>I think it needs to be acknowledged that many people don't get subtle feedback. If you give me subtle feedback, either positive or negative, chances are I will miss it all together. I need feedback that is clear and obvious, what others could categorises as being blunt or abusive
Again: An implicit assumption that either the feedback has to be subtle, or it has to be abusive. Interesting conflation of "blunt" with "abuse".
There are a few others.
FWIW, in the last 2 years I decided to read multiple books on effective communication. Pretty much all of them, at some point, will explicitly call out this false dichotomy. The mindset many tend to have is that either you have to preserve a relationship and risk the message not getting across, or be harsh while risking the relationship. The books say that at the very outset, this mindset is one of the main reasons people are poor communicators. As long as one believes in this reality, he/she is dooming him/herself to having poor communication skills.
One of the books even gives it a name: The Fool's Choice.
Once you spend time studying it, and then start observing real effective communicators (at work and in other arenas), you'll find many of them practice the skills in the books, and you'll suddenly see why they are effective.
Changing your own style, though - it will take a lot of work. Expect change to be slow, and it may take years for you to get there.
Finally, one other comment straddled this Fool's Choice:
>but rather to separate the firmness on technical issues from politeness on personal description. That is, to say "this code is awful" while also a) going out of your way to praise the things co-workers/subordinates do well, and b) when it is appropriate to make general judgments on their performance, make it clear that they are appreciated.
Please don't do this. At least not as stated above. Everyone hates this. Some feel the positive statement is insincere, and planted just to soften the blow. At the other end of the spectrum, some take the positive to heart and the positive message actually lowers the severity of the negative in their minds. "Yeah I screwed up there, but it's probably not a big deal. Overall I'm still doing OK"
If you want to highlight the problem, go ahead and do it. "For me, your code is problematic because X, Y and Z". Explain why X, Y and Z are bad things. Where you go from there depends on what X, Y and Z are, but usually the next step is to try to identify concrete actions the person can take to prevent the problem from recurring (e.g. use a static analysis tool, or a linter, etc).
On the side, code reviews are challenging conversations, because there are very few objective facts. Almost all the (nontrivial) good practices in programming are opinions (including modularity and cohesion guidelines). Never pass an opinion off as a fact. At some level, the team should have coding guidelines/standards. If the team doesn't, then the employee using poor coding practices is not the problem.