A good posting. However, I would suggest taking it a step (or two) further.
For my standard practice, in addition to scheduling the sp_cycle_errorlog to run every night at midnight, I also increase the number of logs to 30, so that I have 1 month of log files to be available. I do not have any empirical evidence to suggest 30 is better than 10, it just seemed a decent number to keep.
I also suggest that recycling the errorlog can increase performance. In my travails as a consultant, I will often come across a client complaining of SQL Server performance issues. Naturally, one of the first things to do is check the error log, and I will occasionally see errorlogs reach gigs in size. Trying to open the file will take forever, so I run the sp_cycle_errorlog sysproc to cycle the file and copy it to my local system. Almost immediatly, I will find a modest performance boost. Usually there are more issues to take care of, and I don't claim it to be a best optimizer solution. But I suspect that if we have a slow, long time opening the reading the errorlog file, SQL Server probably has a slow time opening the file to write to it. I suspect that keeping the current file to a reasonable size helps to keep SQL Server running efficiently.
