When using Jenkins to trigger some process (eg a remote build) at a remote location, why would you ever want to "fire" something, and then just "forget" about the outcome of what got triggered remotely? At least that is what "fire and forget" seems to be about.
Such "fire and forget" sounds like not respecting some of the basic rules in IT: in whatever process (or program, etc) you write, try to always be prepared for unexpected conditions (return codes, etc) that may arise. So that you'll also have appropriate error handling in place.
To the extend it does make sense, in the (mainframe) SCM tool that I'm most familiar with, you'd start some FTP process from a dev environment to a remote target (eg to distribute and activate executables). And sooner or later (asynchronously) somebody gets some kind of acknowledgement back (from the remote target to the dev site) that indicates "success or failure". And if within a reasonable amount of time no feedback at all is returned, you know that something is not working as it should. Using such scenarios, you'll never forget what got fired.
Any examples for which using "fire and forget" in Jenkins does make sense?