but there is no maintenance plan in place for the backup (e.g. they literally backup the files from the disk, so truncating does not happen). The recovery mode is FULL (SQL Server 2005).
I guess previous users were taking file system backup which in my opinion is not best practice when you have important app running. You can never get point in time recovery. Your thinking is correct about creating a maintenance plan backup it gives you more control on backup. Plus if you don't want point in time recovery you can put database in simple recovery mode and can just have full and differential backups as per RPO and RTO. This would avoid the hassle of transaction log file backup and unnecessary growth of log file
This is a bit of a "how long is a piece of string" question, but just need a ball park figure really of how long a truncate will take. Is it likely to be minutes, hours or days for a 60Gb log (the machine is reasonable intel 4 core 2.5Ghz 8Gb machine (not SSD drives))?
First please note log truncations and transaction log backup are not same thing.Its transaction log backup only which is responsible for log truncations in full recovery mode. For DB in simple recovery mode checkpoint causes log truncation or when log grows 70 % of its size.
Regarding how much time transaction log backup of 60 GB log file would take its hard to predict there is not such formula. If you have faster disk where log file resides and faster disk where you are dumping the backup it would take normal time. Backup reads data from disk and writes it to disk so if disk is not facing I/O contention it would be quick.
You must also read
Optimizing backup and restore Performance in SQL Server
Understanding SQL Server Backup