No. You can restore a Full Backup (any Full Backup) and then restore the Log Backup taken after that time, and then all subsequent Log Backups, in chronological order.
However, you do need to test a restore to prove that point! It WILL be critical that the restore can be done WITH NORECOVERY otherwise it will not be possible to apply Log Backups.
Me too. Those sorts of SQL Agent backups terrify me; the tape they are being backed up to has to be recoverable, so in the event of a hardware failure on the server, in several years time, a suitable/compatible tape drive has to be found and the software installed with the right version [to be able to read THAT tape] and configured to be able to restore the backup file. It may be critical that the server has the same version AND Patch Level even!, of MS SQL installed before the restore will work.
Also, if you want to do a restore, following a disaster, when time is critical, you have the delay of recovering from tape - when the tape drive might be busy with other backups / restores, and if the restore fails you then have to wait for an earlier tape to be restored and so on.
I would also have concern as to whether the database can be restored, from backup, to a Newly Named database. For example, someone deletes some data by accident and you need to restore just that (not the whole DB); you can restore the backup to a New, Temporary, database and then INSERT the missing rows into the production database to copy then across. Or you want to do a fraud investigation. Or you want to do a test restore, to make sure that you can ... certainly don't want to do that over the top of the original DB!
That said, if the SQL Agent they are using is a well known, and trusted, brand then it all should be fine (and there are advantages with such tools - such as being able to restore a single table direct out of the backup files).
No (unless it, too, is taking Log Backups - you need ALL the Log Backups, undamaged, in order to do a restore to point-in-time)
Just in case the other utility is taking differential backups you could take a COPY Full Backup (which won't break their backup chain).
Either way, I would insist that your client make a trial-restore, including Log File restore to point-in-time, to prove that they can and you should take no responsibility for their 3rd party backup product. Clearly their IT guy is happy with it, that's fine, just its not in your skill set so the client needs to take responsibility for backups
Here's my 2p-worth:
Backups to disk files means that there are some/many backup files available online, before they are purged. The files can then be copied to Tape/Cloud "at some future point", e.g. overnight (we also copy them, immediately, to an offsite stand-by server). We keep Log backups for 3 days, differential daily backups for a week and Sunday full backups for 4 weeks. I can restore from any of those without having to ask the IT guys to restore from tape for me (actually in our case it would be "restore from Cloud", but same difference, I can't do that myself, I have to ask a colleague)
The backups are made using standard MS SQL software, supported on future versions (typically MS supports restore from two earlier major version), it is independent of Patch Version.
I can easily copy a backup file to a different server and restore it (for testing, or DEV work, or to do a Corruption Check on the DB itself). I can easily restore to a different named database. I can restore log files, in additional to restoring from a full backup, to any point-in-time.
Clearly the Client's IT Guy is a twit. He is happy with a full-backup-only approach and doesn't understand the benefit of being able to restore from a Log Backup to point-in-time. The Business Manager will definitely understand the benefit when you explain that he can either have a restore from Last Night at 3am, or "any point in time with a maximum of 10 minutes data loss" (or whatever backup frequency your log files are ... we used to do hourly, then 10 minutes became fashionable, and now lots of places are doing log backups every minute - same total disk space used each day,. just lots more individual, smaller, files 
(there is some "overhead" in each of the files, so not entirely "same disk space"). If you don't already have a very frequent backup interval for your log files I suggest you consider that; it makes no sense to take Log backups ay more than 10 minutes apart (and don't get "clever" postponing them overnight . you will probably be doing Index Rebuilds then which will generate more log data than users during the day!)
It might well have been that your Log Backup would have worked after the next 3am backup was taken.
