The normal shutdown includes a
sync at the end, after disks have been unmounted (or remounted read-only, in the case of the root file system). Normally, this should do nothing, as file systems are already synchronized on
umount, so data should have been written during the "Unmounting file systems" stage.
Because network file systems can take arbitrarily long to unmount when the server is unreachable, certain init systems implement a timeout on
umount, and because disks can not be unmounted if mountpoints inside them are still mounted, this can cause a cascading failure to unmount file systems cleanly, in which case there may still be unwritten data when the shutdown point is reached. The final sync then makes sure that no data is lost even if the file system is not cleanly unmounted. The file system check and/or journal replay (depending on file system) on the next boot should clean this up then.
The final sync runs at a time when (ideally) no read-write mounts exist, and no other program is still running, so no new write requests can be generated after this point. Zombie processes holding open file handles to deleted files should also have been cleaned up by this point.
Disks can implement their own caching, which is supposed to be fully transparent, but Linux generally sends a shutdown command to the drive nonetheless and waits for that to be reported as complete; drive firmware is generally smart enough to complete all pending writes before that.
For USB devices, SCSI commands are wrapped in USB packets, so the same sequence works for them, but because USB is a lot slower than SCSI, the kernel caches usually grow a lot bigger, so
sync can take several minutes to complete here, but the kernel will dutifully wait.