Time to apply transaction logs: does it matter how many logs?
There is a very small amount of overhead associated with reading headers from backup files.  The more backup files, the more overhead needed; however the amount of data actually read for each header is relatively small. The actual rollback/roll-forward work performed by SQL Server would be no different - SQL Server looks at the transactions in the restore file, and applies them to the database.   

If your database has a lot of transactions per second, then each log backup will have a fair number of transactions within it, and the above logic applies.  If, however, you have a very low number of transactions over the 5 minute period, then the amount of data in any given 5-minute log backup would be quite small, and having lots of small log backups might increase the time needed for restore.

Having transaction log backups taken every 5 minutes, instead of every hour, gives you more up-to-date backups.  You could conceivably take that a bit too far, by say, doing a BACKUP LOG every 15 seconds.  This would create a huge number of backup files that would result in a myriad of other issues such as time required to read the file system structures for the folder containing the backups.  The key here is to use a bit of common sense, and balance the need for recent backups against the need to keep the number of files as small as you can.