Synthetic will not work with DB Transaction logs. At the application level / db level, the T.logs are always fresh new, you cannot combine old ones to make a new one.
Because of the way DB T.logs works (not just MS SQL, but all DBs), for as long as you have a T.log backup, you could always use point in time restore.
You could even restore pass the point the backup was created, by utilizing Tail-log backups and restores, which is also supported by Netbackup.
Because of how flexible PIT + Tail-log restores are, the need to make extremely frequent backups is somewhat mitigated. Hourly T.log backups should do in most environments, unless your's has particularly strict requirements.
Sometimes even hourly T.log backups would be overkill, depending on how frequently the DBs are updated. Best to discuss with DBA.
I would recommend something like a weekly full, daily cumulative ("differential" in MS SQL terms), and hourly differential (T.logs in MS SQL terms).
You will need 3 different policies because of 3 different .bch scripts.
The best Nbu document that explains the SQL T.log restore concept is actually not the Nbu SQL or Oracle guide, but the Enterprise Vault guide, under the section "About backup image restore sets".
The only way you could time the duplication hours would be to use Nbu Vault.
If not then you could always try the OS scheduler jobs to trigger SLP active/inactive scripts.
