This question was attempted twice on experts-exchange with no real answer.
I know that I should not shrink the log file - that is not the question.
If you feel like answering that one should not do it- that has been confirmed many times yes and it is not the goal of this question.
Setting to Simple backup is also not an option.
It has been bugging me for years - the fact that I do now know why it should be backed up twice.
I recently saw the first log file that was able to shrink every time on the first attempt - it was unbelievable. I asked the guy about it and all I could make out was "reorganize before releasing" - I do not know what he was referring to. I am not able to contact him again.
I know this from the existing posts on E-E: "Shrinking removes inactive parts of the log. In order to be inactive, the log must be truncated which occurs as part of log backup.
However, transaction log is made up of many virtual log files that are used in a round robin fashion. Only virtual logs at the end of the file can be pruned so if SQL server is currently using the last virtual log, nothing can be removed. The old fix in sql 7 was to run a script that ran enough dummy transactions to fill up the log and wrap the pointer around to the first virtual log (you can still use this method if you prefer).
http://support.microsoft.com/kb/256650/EN-US
DBCC now does this for you but still requires the extra step of truncating the log again so the inactive space can be deleted"
From another user: "All I had to do was discontinue the automated optimization and integrity checks the last Admin had left on the database maintenance plans."