The only downside is that it causes more thrashing on the disk, so worse performance.

A single write will require 2 seeks (between: write transaction log, write data, commit log). Having the transaction log on a separate disk means as few as zero seeks, because the drive heads can remain on the transaction log and the data.

A hard disk drive will perform fastest if it is doing sequential writes or sequential reads, because the drive head doesn't need to move around.

SQL Server log files happen to be sequential, so if you dedicate a hard drive to ONLY the logs, you will see a noticeable performance improvement. That said, for smaller databases where performance is not an issue, it doesn't matter.

And as for Nir's comment on drive failures -- hopefully you are handling that at a lower level, by putting both your data and logs on RAID arrays.

Actually in simple mode there is still a transaction log. It's just that once the log is no longer needed by SQLServer it's trashed. In simple recovery mode the log is not kept around for recovery. You're recovery is "simple"... just restore from your last backup.
–
Walden LeverichMar 10 '09 at 17:37