Criticizing the code itself (with useful feedback), and not the person who wrote it, gives them a chance to own up to it if they're comfortable with doing that. And if not, you're still able to improve the codebase without directly calling them out.
If they get pissy about it, that's on them.
A critical skill for a senior engineer in a team is to define and establish such standards for the team. Rather than reacting to each design/code review, taking the time to setup these process mechanisms is a lot more productive and healthy for everyone involved.
This requires strategic thinking (a skill that comes with practice) towards how you choose to spend your time at work to accomplish anything.
A lot of projects lack that "objective standards". I've been helping to solve exactly this. But code can be messy without having a clear defined "clean code" standard. And a project can perform horrible, without having minimum response times docutented.
Often my job was to define all those. And often those definitions already hit a nerve. When suddenly your code is marked as "far too tightly coupled" or "too complex: AB above 34" when you thought it was neat and smart code, that is confronting and, I've seen, is often felt as personal critique.
How did you go about doing that? (How did you warn others about an oss project, ... Maybe one/some project at GitHub?)
Maybe when someone somewhere asks why I don't want to include X-lib or Y-dependency, I'll explain why for this case its not a good choice.
Generally, I keep this to the consultancy-reports and on-premise discussions though.
I would have appreciated working with you/people who gave some critical thoughts to third party dependencies.
I hope that each time you go to a new employer, you try again and see if they're happy with getting such warnings
I always try to praise a person. But I also want to "reserve all rights" to say that a codebase is crap or a choice made in the past was evidently a bad choice.
Finding the balance to critique work that a person contributed to, without criticising that person itself, is hard. A true challenge, I found.
It becomes even harder if a project is Open Source and you truly feel you have to "warn" people against using a solution in certain cases. It then becomes really hard not to sound like a grumpy old neckbeard or someone with a grudge. I lately decided it is best to just shut up, and let people find out themselves; to let them fail, fall or possibly succeed and prove me wrong instead. I do see the arrogance of that too, though.