- It's a lot easier to welcome feedback that comes in a form like "can you tell me about xyz?" [answer] "would it make sense to do abc instead?" than "xyz is shit, let's rip it out and do abc, jesus"
- the ego of the new employee shouldn't make them feel above learning the nasty details, or be fragile enough that they get frustrated if the answer is something like "abc might have some other problems, we're thinking about doing ijk, but in the meantime we don't touch this code much and it's not in a public-facing area, so we have other stuff higher on the roadmap."
The manager can also avoid a lot of potential problems by being up front about "by the way, here are the pain areas we know about, we're slowly tackling them one by one, let me know if you spot anything else you think we could add to the list."
So you come to the code trying to understand why it is that way, and the developer will criticize it themselves.
And then you understand that you weren't wrong, and the opportunity for improvement is there, when time is available, but you haven't risked alienating people by treating them as if they're idiots for writing imperfect code.