Unmounting a filesystem will sync all the associated cache-in-memory data. The reboot() call can lose data, exactly because it does not unmount the filesystems cleanly. (lennart is salty about this :-).
However I would only call the filesystem "broken" if it was not using journalling (or equivalent). Apart from that case, e.g. ext4/xfs/btrfs should be repaired 100% reliably using the journal. This can be (and is) performed automatically. Unlike a full check/repair, it does not involve scanning the entire filesystem, so it is pretty quick. Unless you had a lot of unsynced metadata changes that need to be sorted out.
You can see some example messages from ext4 here: Does "recovering journal" prove an unclean shutdown/unmount?
In the linked example, it appears that
fsck.ext4 recovers the journal. However, I think the kernel can also recover the ext4 journal automatically when the filesystem is mounted. For xfs/btrfs,
fsck never does anything (see the relevant
man pages), so it is always handled by the kernel.
ext2 did not have a journal.
fsck.ext2 has a good reputation, but as I understand it, it does not cover every possible case that journalling can. It might end up losing filenames and dropping their content into the
lost+found directory. Or the correct fix might not be 100% unambiguous, so it would need to ask the user permission before applying its best guess.
The above assumes your storage device fulfils the filesystem's expectations. For example there is a known case regarding power failures which interrupt write operations: some SD card style storage may lose the entire 128KB flash erase block, that contained the disk block (e.g. 4KB) you were writing to. The above filesystems are not designed to survive such data loss :-).