Maximum size transaction log and impact
You are looking at the problem wrong.  

Assuming full recover; the size of your transaction log (T-log) is determined by your work load and how often you take log backups.  

It is completely reasonable to have a 3 TB database with a 1 GB T-log if there is a lot of old data, that has simple reports run against it occasionally.  Backup the T-logs hourly and it may never grow. 

In most cases you will want to take T-log backups every one to four hours.  How much space is required to hold the T-logs for your heaviest work load in that time defines how big your t-log should be (plus a bit extra just in case).  

If you have a virtual server, use a separate drive for for the T-logs.  For a brand new build, in most cases I start with 10GB of disk and start the ndf file at 250MB, watch it grow (auto grow 50MB) for a few days or weeks and then decide "What is the right amount of VLFs for my requried log size?" then I adjust them.  I recheck about every 3 months. 

See my post about VLF files here

Edit 


  not matter what downtime 


There is no down time for the fix, you want to do it off peak hours partly to reduce resource competition, but mostly because you want to get the ndf file as small as possible before you start a planned growth.  It is easiest to do this when there is little or no activity. 


  tune autogrowth to prevent VLF fragmentation


Not really sure what you mean by this.  VLF files are written to in sequence. One gets full, the next available in line gets written to.  


  I can imagine that log backups will take longer because the log backup 


Maybe a minuscule impact, but nothing worth worrying about. 


  impact of a scenario where a transaction log is huge


If you are not currently having performance issues, impact is mostly limited to restore times.  Which is more related to the number of VLFs as opposed to the size of the file.  

If you are having performance issues, they are likely tied to indexes or something data or procedure related or possibly hardware.  If it the performance issue is index related, you want to fix it and get regular index maintenance started, then address VLF files (because heavy index maintenance is hard on t-logs, the first time)

In short, do VLF maintenance when you have the opportunity. It has been ugly for a long time.  You are not going to see any magical improvements in daily performance.