Yeah, transaction logs usually* have a constant but very low throughput, when compared to the whole database. But the throughput is absolutely first priority, when it is delayed, all updates to the database have to wait. It is economically beneficial to write logs to a mirror, or even to a RAID5, but only as long as you can keep your writes sequential. If you share the disks with anything else, be it a data file, an index, or collection of porn movies, you are putting your performance at risk.
In larger environments, the thing is usually you have multiple database instances centralized on the same storage. Of course, you don't want to put the logs together on the same set of drives, as multiple sequential writes combined make in fact one big random-like write.
One option is to dedicate a separate mirror (two disks) to each log sequence. But another option - and economically viable in some cases - is to keep things simple and use single SSD for all the log files, so you have separate device and data path, with good random performance. In effect, any of multiple logs will never delay any database. I've seen such setup, but I don't recommend it (SSD's non-volatility is too fragile concept for me).
[*] - some engines mix redo logs with undo information to complicate things (e.g. MS SQL Server)