My understanding of the differences, it may not be 100% correct from a "File Systems Guru" POV, but should be close enough. Apoligies in advance if this gets long. Feel free to correct me on any terminology that is wrong.
Mount options sync vs async vs "noasync" is about performance and data integrity.
sync is "a write operation to disk not not complete until both metadata and data blocks have been written to the physical device". Michael W Lucas in his "Storage Essentials" book calls sync writes "stupidly safe". There is a performance penalty for doing all writes sync. But what is on the physical device should be consistent. Hard power loss can still result in data loss.
async is "kernel tells the caller that data is written once the operation has been dispatched". That means the data may or may not have been written to the device, hard power loss pretty much guarantees data loss here. So why would you use it? Temp file systems don't really need absolute data integrity, so anyplace you need performance and don't care about dataloss, async is good.
"noasync" is an hybrid mode that effectively is "async with inode affecting data written synchronously". So metadata is treated as sync, "data" async. This used to be the default mode for UFS filesystems, to the best of my knowledge it still is.
Now add soft updates (SU) and soft updates with journaling (SU+J):
SU is basically "organize and arrange disk writes so that filesystem metadata remains consistent at all times". SU strives to make the physical device internally consistent, but again, power loss at the wrong time means you lose data because it's in RAM and noth physically pushed to disk. Yes your point about "30 to 60 secs earlier" is correct/close enough. Think about the path to write something to a physical device. Data in RAM at the program level, gets pushed to kernel buffers, kernel buffers get pushed to file system handlers (VFS layers), file system handlers figure out split between meta data and data (determines what needs to be done), some writes get pushed to a soft updates process where they may get reordered, then periodically runs and flushes to the physical device. So yes, until something is flushed it only exists in RAM and can be lost.
When you gracefully shutdown a system, all the "syncing buffers" messages you see are the kernel running active buffers and flushing them to the physical device.
Oh, ZFS also does something akin to soft updates, look up transaction groups if you're interested.
SU+J is "record metadata updates outside of the filesystem before updating the filesystem". The journal comes into play on system boot/fsck: comparison of whats in the journal against what's on the physical device and "replay transactions" as needed.
One needs to keep in mind how big disks were (not very, 100MB was huge at one point) when UFS was created. UFS starts to run into limits as the physical devices get larger, I think there is roughly a 2TB limit on the size of a filesystem, hence everyone talks about "UFS on smaller/embedded systems".
Journaling helps when the devices/file systems become large, unless you want to spend a lot of time waiting on fsck at boot.
The default at one point for UFS filesystems was "mounted noasync, with soft updates enabled", that provided good combination of performance, data integrity and resilence (minimal data loss on hard power loss at the wrong time).
Mount sync with no SU or SU+J should be the overall safest (minimal data loss) but performance hit and possibly long boot ups for fsck (again, becomes important as devices grow larger).
gjournal: "Journal at the GEOM level" or a layer below the filesystem but above the physical device. Works, it's transparent to the filesystem, lets you do all kinds of things like "journal a FAT32 filesystem" (just because you can, doesn't mean you should).
More coffee then time to walk the dog.
from single user mode. The mount command outputs (ufs, local) instead of (ufs, local, journaled soft-updates) for my ada0p2 after reboot.