Automated systems are supposed to send to Sender, except when they're not... well, it depends on what you mean by "automated". In the "classical" sense, the only automated system was the software that implemented SMTP itself, such as sendmail. It generated bounces, it generated vacation replies, it was both the point of mail ingress and egress for mail's state in the system.

Now, there are automated systems that exist outside of SMTP. For example, mail user agents generate vacation replies. Things like gmail and Exchange/Outlook blur the line between mail server and mail user agent. SMTP generated bounces are rarely useful for humans, but things like vacation messages are intended for humans. If there is a reply-to, that's assumed to be more of a human (a human who will at least read the response, bounce or otherwise) than the chances that the Sender (on a message with a Reply-to) is going to be a human.

So, if you're talking about bounces, I'd expect them to go to Sender. For vacation messages, I expect them to go to Reply-to. And of course, YMMV, even MMMV, based on the email topology of any specific organization. What counts as a bounce? What counts as a auto-reply about the availability-state of the recipient? Or the availability-state of the person/role collecting the recipient's email? Is that significantly different from a bounce? Can an automated system determine that? Should it?

(sidenote: Personally, I hate vacation messages. People think it provides an explanation for not immediately replying (anyone who thinks email is reliably immediate is an idiot), but all it does is show you care more how you don't respond when you're not around than when you are.)

Some of them do, some of them don't. Email is a very old system, and for some things there's no standards, for some things implementations predate standards so one has to live with what is out there. Some of them just broken and since there's often no standard to point them to they just say "well, we know there's industry practice to do X, but we prefer to do Y".

This is the problem. I've helped build my company's bounce tracker. There is an RFC that explains how you are supposed to do things, but at least 50% of email servers don't follow it.

You may get your whole email back, or just the start. The message may tell you what went wrong, it may not. It may tell you what email address you tried to send to that failed, that may be missing (some mail servers actually redact it).

The worst one is when they successfully deliver their bounce to the Return-Path but then corrupt the To on the bounce to be the To on the original message and then copy their Message-ID into the original message, thus removing any chance of successfully processing anything. I never figured out the actual MTA that was doing this, but Lotus Domino was involved.

shakes fist