I think I missed a very important point in the article - that SHRINKFILE on a Log file ISNT the performance killer that shrinking a data file is. The problems come from moving data around inside the file(s) causing fragmentation.

Shrinking a Log file is a very different operation to shrinking a data file. You can only shrink a Log file down to the boundary of the last used VLF (Virtual Log File). Data (i.e. log records, not data per se) doesn't get moved around in a log file in a shrink operation. You can see this by the fact that a Shrink operation on a Log file often doesn't clear all the space you were hoping for - SQL has identified the last VLF that has an active transaction, and that's how far it will shrink the file to, no matter how much free space there is before that VLF. This is a good explanation about Log file architecture http://technet.microsoft.com/en-us/library/ms179355.aspx.