If you worry about write cycles, you won't get anywhere.
You will have data on your SSD that changes frequently; your home, your configs, your browser caches, maybe even databases (if you use any). They all should be on SSD: why else would you have one, if not to gain speed for the things you do frequently?
The number of writes may be limited, but a modern SSD is very good at wear leveling, so you shouldn't worry about it too much. The disk is there to be written to; if you don't use it for that, you might just as well use it as a paperweight and never even put it into your computer.
There is no storage device suited for swap space. Swap is slow, even on SSD. If you need to swap all the time, you're better off getting more RAM one way or another.
It may be different for swap space that's not used for swapping, but for suspend-to-disk scenarios. Naturally the faster the storage media used for that, the faster it will suspend and wake up again.
Personally, I put everything on SSD except the big, static data. A movie, for example, doesn't have to waste expensive space on SSD, as a HDD is more than fast enough to play it. It won't play any faster using SSD storage for it.
Like all storage media, SSD will fail at some point, whether you use it or not. You should consider them to be just as reliable as HDDs, which is not reliable at all, so you should make backups.
async is the opposite of sync, which is rarely used. async is the default, you don't need to specify that explicitly.
The option sync means that all changes to the according filesystem are immediately flushed to disk; the respective write operations are being waited for. For mechanical drives that means a huge slow down since the system has to move the disk heads to the right position; with sync the userland process has to wait for the operation to complete. In contrast, with async the system buffers the write operation and optimizes the actual writes; meanwhile, instead of being blocked the process in userland continues to run. (If something goes wrong, then close() returns -1 with errno = EIO.)
SSD: I don't know how fast the SSD memory is compared to RAM memory, but certainly it is not faster, so sync is likely to give a performance penalty, although not as bad as with mechanical disk drives. As of the lifetime, the wisdom is still valid, since writing to a SSD a lot "wears" it off. The worst scenario would be a process that makes a lot of changes to the same place; with sync each of them hits the SSD, while with async (the default) the SSD won't see most of them due to the kernel buffering.
In the end of the day, don't bother with sync, it's most likely that you're fine with async.
Best Answer
If the SSD is to be your only disk platform, regardless of number of devices, then you have a quandry; how to minimize writes while maintaining reliability and performance.
More specifically, ext4, and 3 for that matter, NILFS, and almost any other modern file system will maintain a journal. Ordinarily this is desirable, however, when dealing with SSD devices it increases the writes performed against the device and thereby reduces its lifespan. One option is to select a conventional IDE, SATA, or other device to which the file system can write its journal. This way one may maintain the benefits of journaling without sacrificing lifespan of the SSD device(s). In the case of ext4 this can be accomplished as:
mke2fs -O journal_dev /dev/external_devicethen attached to the specific file system as:mkfs.ext4 -J journal=/dev/external_device. More information can be found in the man page.An additional feature of file systems to keep in mind when deal with SSD devices is atime. Setting atime on a file system can drastically increase the number of writes to a given device over time. Options for changing this behavior include 'relatime' and 'noatime'.
Since we seem to be focusing on ext4, the kernel documentation on the file system, including its available options, is available for reference here.
Some other options to consider:
noload, as vorbote suggested, anderrors=remount-ro;