The situation, as you describe it, seems beautiful.
Backing up the transaction log does not compress the log file. However, it truncates the log file, which means that the space can be reused:
From books on the Internet ( Trimming a transaction log ):
Log truncation automatically frees up space in the logical log for reuse in the transaction log.
In addition, from Transaction Log Management :
Log truncation, which is automatically under a simple recovery model, requires that the log is not populated. The truncation process reduces the size of the logical log file that is marked as inactive virtual log files that do not contain any part of the logical log.
This means that every time a transaction log is backed up in your script, free space is created in the file that can be used by subsequent transactions.
Following this, also need to compress the file? Generally speaking, the answer is no. Assuming your database does not suddenly have massive one-time bursts in use, the transaction log will grow to fit the typical workload.
This means that if you start to shrink the log, SQL Server just needs to grow it again ... This is intensive work with resources, affecting server performance, and no transactions can complete while the log grows.
The current size and file sizes seem reasonable to me.