That would be my general advice. A crashed process is a potentially-compromised one, and what you can do by sifting through the wreckage is always going to be limited. Along similar lines to what you said, a robust program should also be able to "crash on success" and simply terminate the process once it's ready to quit without needing any cleanup on the way out. Admittedly, persistent shared resources such as terminal status or (as you noted) temporary files aren't always friendly to this ideal.
If you do want to observe or react to a process's abnormal termination, and your target platform is amenable, a more robust way to do so is to have a minimal parent process that spawns and monitors a child process that does the actual work. That way, if the child process does go awry, the monitor code won't be compromised, and you can perform cleanup or logging actions without having to worry about being signal-safe or spreading corruption. The Swift runtime itself takes this approach when its builtin backtrace functionality is enabled.