The problem relates more to 32 bit OS's caching disk writes. Dos didn't do any disk caching, so hitting reset wouldn't corrupt anything (unless you were in a rare long disk write process at the time of reset). Linux, Windows, Most Unix's, and other 32 bit multitasking OS's utilize disk caching techniques to speed up user performance on a system by writing to the disk between user app cycles. The chances of corrupting a disk by hitting reset in Linux, thus, are far greater than in Dos, but are not a definite result. For example, hitting reset on a system that is sitting idle, with virutally no cpu load, and no swap file usage, has a lower chance of corruption than a system that is under a greater load, and writing to disk constantly.
To better help fight against disk corruption, most file systems implemented in Linux set a flag on the partition when mounting it r/w, so that if a reset does occur, it will automatically check to make sure nothing got clobbered. Using a journaling file system (ext3, JFS, Reiserfs, etc) makes the system more stable, as it can store a disk write command in a journal, then mark the journal entry as completed once the actual write has finished. When rebooting a running system with a journaling filesystem, the system detects a dirty partition, then looks through the journal for incomplete writes, backing out any changes that were incomplete.
Hope this information was helpful.