SQL Server Backups-Order of FULL & T-log backups
Can anyone think of a good reason for taking a FULL and then a t-log
  directly after? I tried asking the employees that have been here but
  they are clueless.


The reason I can think of is to 'truncate' the Transaction Log since the last full backup happened. If you would not do these log backups, the log would keep on growing.

If truncating the transaction log is the main reason then you should just set your database to the SIMPLE recovery model instead. This means that you will lose data up until the last full/diff backup. 

But it would be no different with the current method of taking backups. 

Unless some restore procedure is using STOPAT to restore to a point in time after the log backup has happened. (this still means data loss up untill the last backup, possibly +10h) 

Another reason could be that the database is part of an AlwaysOn AG, but this should give you even more incentive for more frequent log backups.

The main issue

The main thing is, the log backups cost the same, wether you run them every minute,every 15 minutes or every 10 hours. Take a look at this blog post by Brent Ozar as to why it should not matter how often we schedule this (without getting too crazy). 

Running them once before every full backup is not what they where designed to do, you should schedule them more often. 

Something I prefer is this backup solution by Ola Hallengren, instead of maintenance plans.

Long story short, I would schedule log backups more often, the default people tend to use is every 15 minutes, but it depends on your RPO.


  But are there any unobvious implications by taking the Full and then
  the log directly afterwards? 


There should not be any issues with doing this, other than the remarks mentioned above.