The options available are read-only filesystems , read-write filesystems, both as runtime and/or dedicated boot filesystems. Naturally one can go for a raw medium with a compressed filesystem image - this will give you the smallest possible boot-image size and thus the least storage demands but will result in a had to manipulate and not very robust filesystem with respect to media errors.
Read-ONLY root-fs: romfs, cramfs
Readonly filesystems have a clear advantage - you can't modify them at runtime even if you gain root-permissions. They have a just as clear disadvantage, if you want to update the filesystem the entire filesystem must be replace, if something goes wrong you might los access to the device completely and if your embedded GNU/Linux system is on a satellite 64000k above the equator... even if it's a bit closer than that updating read-only filesystems is a problem for any device you don't have physical access to.
Read-Write root-fs:
Jffs2 is compressed but must do a full scan on boot up which results in a somewhat slow mount operation, generally this is only of concern for systems that have to provide extremely short boot-times - so if this requirement is given then a compressed filesystem is probably not the best solution (assuming that a system requiring fast boot up will not have a slow boot-media, which would off course profit from a compressed filesystem). It can be read/write mounted after booting , at system boot it generally will be accessed read-only . Support for jffs2 as boot-filesystem is moving into the boot-loaders slowly (grub ppcboot), but currently booting of jffs2 is not straight-forward. The obvious advantage is the flexibility of a read/writable filesystem and the efficiency due to compression. One point that applies to other boot-filesystems as well is that it is non-trivial to access and modify boot-file-images based on jffs2, at least not for the untrained personnel.
Using an msdos filesystem as boot-media is a simple way to get some devices to work with Linux especially if the boot-medium comes with a DOS-filesystem pre-formated and the intelligent BIOS will not boot from anything else. A further advantage is that it is supported by many OS's so if the filesystem resides on a removable medium and requiring a Linux desk-top for manipulation is not acceptable to the company, then an msdos file-system can be a solution. As long as you don't write to it during a power-loss msdos is quite robust, and it is quite efficient with respect to the overhead the filesystem will require. The most notorious limitation of msdos though, is the well know 8+3 name-length limitation and the case insensitive behavior. For these reasons msdos boot-fs is to be considered a last-option in my opinion.
As noted above for embedded systems minix also is used quite frequently, this actually is a UNIX filesystem, it is though limited with respect to the supported file-name length (30 characters) and the maximum directory depth, the later generally is not a problem for small embedded systems, 30 character name-length restriction is an issue, as minix will silently truncate filename length so this potentially can lead to hard to locate problems. Minix is relatively efficient with device usage, especially if it is on a boot-device with very few files limiting the number of inodes at filesystem creation to the actually required number can optimize media usage quite well.
standard Linux FS: ext2
For embedded systems that have plenty of disk-space available an ext2 file-system is fine, it's fairly robust and most linux users are acquainted with using it, so there are little handling issues involved with ext2. One problem with ext2 as a boot file-system is that if it ever becomes inconsistent it requires user intervention at the console (typically if you do a few power-fail sessions in a row...) and it also will mandate fs-checks to be run after N reboots (N being somewhere between 10 and 20 commonly , but that's a configurable parameter). The wide use of ext2 is also due to some boot-loaders (notably LILO) not being able to boot of journaling filesystems like reiserfs or jfs directly so commonly systems have a ext2 boot-partition even if running of some other file-system during regular operation.
journaling fs: reiserfs, ext3, jfs, jffs, jffs2
For all embedded systems that must prevent requiring the ability of direct user interaction at the console should use a file-system that is fail safe against power-loss even while writing. This class of filesystems has been becoming available on linux systems within the past year or so and has now matured to a point where it actually is ready for production systems. For embedded systems with large storage media, like hard-disks ext3, reiserfs or jfs can be of interest, the later two requiring a minimum filesystem size of 16 MB. Ext3 being a ädd-onto ext2 will run on smaller media as well but will not be very resource efficient on small media.
As jffs/jffs2 is covered in a bit more detail below, so here it should just be stated here that it is a journaling file-system that is quite robust to power-fail situations and jffs2 is very space efficient due to its compression. Thus for small media (<4MB) jffs2 is probably the only real option out there in the embedded Linux/RTLinux world.