Why trigger something remotely (using Jenkins) and then just forget about it? 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?
I wouldn't describe Jenkins jobs as "fire and forget."  They are designed to run automatically without the need for human interaction, however, that doesn't mean the result of a job is not visible.  Quite the opposite- detailed logs of all activity are available for jobs ranging from command-line tools to custom deployment jobs.

The testing results from Jenkins jobs are routinely displayed on large-screen TVs all over the Development floor of many companies I've seen.  There are whole plugins devoted to making this type of information available to developers, Ops, and management in a dashboard format.