Shrink log with TRUNCATEONLY but there's nothing to truncate?
Are these SHRINKLOG WITH TRUNCATEONLY events, even if they have nothing to truncate, still causing performance issues?


How could this not cause performance issues?  Even if there is nothing to shrink it takes work to figure that out.  

I would ask them why they are using SHRINKLOG WITH TRUNCATEONLY I expect they don't know why or even that they are doing this.  Even if they know why, there is almost no chance it is for a good reason.  If they have a good reason, you should post it, I doubt anyone has ever seen a good reason for this.  

If the system is in FULL Recovery, the ONLY time you can shrink free space is after the log backup has run.  In the very extreme case when there is a good reason (almost never) do it once after the log backup. 

If the system is in SIMPLE recovery, the VLF files can only empty when when all the inflight work has completed. And you can only truncate the very last VLF, and then the one before that, etc.  Truncating more then once an hour or maybe at the end of the job is the only way you might actually shrink something. See an in depth view in this related Why are virtual log files not always allocated in order? 

Depending on what version of SQL you are running and the current size of the log file, a 2GB grow will create between 1 and 16 VLF files.  The smallest VLF in this scenario is 125MB, so at the very best the smallest amount a shrink could remove is 125MB, see more in this post 

Even if they have a really good reason for shrinking (again I doubt they do) there is not a good reason to do it as often as they are.