It attempts to do so but there are caveats in the man and info pages. To read more documentation on your system you can run the commands:
man 8 sync
man 2 sync
You will see the sync command (man section 8/info sync) just invokes the sync system call (man section 2).
One note seen for sync is:
According to the standard specification (e.g., POSIX.1-2001), sync()
schedules the writes, but may return before the actual writing is done.
However, since version 1.3.20 Linux does actually wait. (This still
does not guarantee data integrity: modern disks have large caches.)
It depends much on where the write is going. As noted above disks themselves have cache. Additionally if you're using a SCSI/RAID disk controller it might have its own cache. If you're writing to an external disk array via fibre or iSCSI it is likely the disk array itself has caching of its own. The key point to remember is that when it says it flushes or writes it what it really means is it has told the memory of the server itself to immediately send it to the storage. How quickly it actually gets physically on the disk depends on the storage itself. In some cases it doesn't really matter (e.g. the external disk array - once the sync has sent the command to the HBA and the HBA has sent to the array then it doesn't matter if the host goes down as the actual write to disk is handled by the array).
Also this is why journaling filesystems such as ext3/vxfs were created. They create intent logs that are more frequently updated than actual writes to disk so in the event of a crash when you run fsck after a boot it will find uncommited extents and update the disk.
Although you CAN lose data in a system crash in practice it doesn't really happen very often. However, ideally you should have redundant power to allow for orderly shutdowns on loss of power because losing data writes especially in DBMS setups CAN cause corruption so you want to avoid it if at all possible.