Ross recently wrote up a blog regarding this topic. However, my general rule of thumb is 7 days instead of 3.
I agree with Bryan – my recommendation is typically 7 days (and then some). In theory, this is so that you can tolerate backup failures for 7 days – presumably failed backup jobs won’t truncate the logs. If you have a couple failures in a row for whatever reason, you may run out of space on the logs LUN, thereby stopping the database. But in reality, it helps mitigate transient issues that generate an abnormal volume of transaction logs (mailbox migrations, MAPI issues, bugs and that sort of thing). You want to make sure you have enough runway to recognize and resolve the problem before the whole database comes down. I don’t think 3 days is enough.
As it turns out, many of my configurations are nl-SAS lately, and there’s nothing about a normal Exchange log workload that precludes it. A handful of nl-SAS disks dedicated to transaction logs results in lots of capacity, so I don’t usually have to worry about it.