The weird thing is though, I still actively encourage new devs to make this mistake in certain circumstances. For one thing, telling them no isn't going to help, we have no shared context, and the math of their productivity versus mine works against me spending too much time convincing them.

If the problem has a logistical or bureaucratic component, once in a while the stars align and they manage to pull off something the department has been trying to do for years but always runs into a wall. Some people in an organization will assume something is true if they hear it from enough independent parties. I know if three people ask me the same question about a block of our code, I start looking at that code suspiciously. Clearly something is wrong with it. Sending the 5th guy to ask some IT guy or product manager he same question, especially in the way a new person tends to formulate questions, sometimes knocks the cobwebs off and the person decides to change their behavior or volunteer to do something they have resisted doing before.

A week of junior dev time for a 5% chance to clear out a bag of tech debt is a good investment IMO. And if it doesn't work they learn something about why things are the way they are.

I had a senior coworker who used to laugh and say "You're new here aren't you?" and I started giving him grief for doing it. Sometimes the new guy is the only one who can get things changed.