I'm always in favor of logging system changes.
Notification at run time is really tricky. No one ever logs into several of my Debian servers. Other systems have interactive GUI or CLI users, some of whom are admins and others not.
I don't know if login notices are terribly reliable as no one may ever see them. I see nothing wrong with having them, but I wouldn't consider them to be a good *primary* notification.
Personally, I would resort to email, as it's most likely that a good admin has at least set up root mail to go somewhere appropriate.
Whether or not root should get copied on notifications sent to other users strikes me as a security question, though if the data to be deleted is in a shared scratch space like /tmp/ then perhaps that's not a concern (and the potential for lost data might override any such concerns anyway, plus the fact that root is, well, root in the first place). I would argue that the role of "root as helpful admin" should prevail in this case and root should get copied.
I, for one, don't want a lot of email, but once the data is gone, it's GONE. I'd rather be notified and have to deal with it than not be told at all.
Sent from my mobile device.
Maybe putting the cleanup task for /var/tmp on a longer timer and warning users ahead of time of impending deletion (maybe 3 days before, 2 days, etc) would help with files of unsuspecting users getting deleted. A log entry could also be emitted. I could see a gentle warning on ssh login (minimal, one or two lines) and desktop notification (for desktop only users who never see the terminal) be helpful. A smarter implementation could perhaps only warn if dirs/files that are going to be deleted are not systemd generated random items. This does not fix issues with applications depending on stuff being there long term; yet again nothing's perfect in software