My experience is more that there's always a bunch of tickets/bugs that are a) not critical b) not 5-minute fixes and c) tend to be "we should really..." - those are optimal, because they wouldn't get done otherwise anyway.
That's a serious problem. Whether work gets done should be independent of whether or not you have new hires around. And what lesson are you teaching if that's how you complete that kind of work? Onboarding is "hey do this thing nobody else will ever do, so we can say engineers ship on day one"
I disagree, it's a much more helpful way to let them explore the code base than "here, write a test for some feature you also don't understand".
Where I was it was never a stated goal to have them ship asap, the goal was a) to let them learn quickly and b) let them not hate their new job.
Incidentally, everyone except one person liked this approach. Hands-on, have the genuine feeling to do something sensible (maybe not important, but hey, it's your first week) and NOT spend 2w just reading docs.
I think that's a false dichotomy. For example, have new hires pair with someone who is making good progress on something medium sized and medium impact. Share in a nearly guaranteed success, learn, and no need to hoard one-pointers.
Does it really matter? Aren't you teaching the lesson that speed is the first principle?
It's just another excuse to avoid building actual onboarding, whatever that looks like for you. Too relaxed, too aggressive... are you really doing it thoughtfully?