I have a really strong opinion on this one which is basically we should all strive to write crash only software.
If the process is sent SIGINT or SIGTERM (often at system shutdown) in the ideal case there is no signal handler - i.e. the kernel just unilaterally kills the process. That's maximally efficient! Unwinding the stack and calling e.g. free() on a ton of String etc. objects is just a waste of CPU.
I suspect the reason you're bringing this up is the interesting problem is around "external persistent" data, such as that created by tempfile::tempdir().
One approach I've been meaning to wire up into a crate is, at least on Linux you can use prctl(PR_SET_PDEATHSIG) to get a signal when the parent exits. So the idea here is that rather than having the parent process do e.g. std::fs::remove_dir_all() in its Drop(), instead we call fork(), have that child set up PDEATHSIG, and pass the path to it over a pipe. (This would generalize to an "external process drop handler"). When the parent exits due to e.g. crashing, the child would clean up. (To correctly handle scoping though of course the parent would should to still ask the child to eagerly invoke the cleanup; debatable whether that should be sync or async)
An advantage of this approach is one can reasonably use e.g. panic=abort and still ensure that things like temp dirs are cleaned up.
The generalization of this "external cleanup helper" is of course things like e.g. systemd-tmpfiles-cleanup.service but that has pretty conservative defaults so tempdirs can remain for a long time.
I don't think Rust can (or should) ever add a default SIGINT/SIGTERM handler.