I suspect that there is some confusion about terminology here.
Maintenance plans do not delete transaction logs. Maintenance plans delete transaction log backups.
Transaction log files are required for the operation of a SQL Server database. Every SQL Server database has at least one transaction log file. By convention, these files are given a "LDF" extension. SQL Server log files do not behave like Oracle's redo logs. You can't just copy a log file and/or delete it.
In your configuration (FULL), when the maintenance plan runs it should be configured to execute a transaction log backup command. This (more or less) makes a copy of the information in the transaction log file and places that information in a separate file called a transaction log backup. The transaction log backup command then marks the relevent space in transaction log file as free for use (again) by SQL Server. If this "marking of space" does not occur, the transaction log will eventually fill up. (Things work differently if the database is running in SIMPLE mode, but you aren't doing that.)
With the FULL model, if the transaction log backup commands do not execute "often enough", the transaction log file can fill up. When that happens, depending on your exact configuration, the transaction log will either be automatically grown or updates to the database will start to fail. "often enough" is determined by how much space you have available, how big your files are, the rate of change of data in the database, the exact nature of how you do updates, your point-in-time recovery requirements, etc. Note that you can schedule transaction log backups in a highly flexible way: once a day, once an hour or once a minute or once every few minutes. You can even run transaction log backups more (or less) frequently during busy periods.
The next time the maintenance plan runs, it will do the same thing as it did the last time but it will vary the name of the transaction log backup file (using a timestamp) so the earlier file is not overwritten. The maintenance plan runs the transaction log backup command based on the schedule that you configure. As the minutes and hours and days pass, an ever-growing set of transaction log backup files is created. At some point, those files need to be trimmed back by deleting them or moving them to somewhere else. If you are running some sort of log-shipping scheme, it's possible that you would be moving the transaction log backup files to some other safe location.
The key concepts here are that the data is copied from the transaction log file to a separate transaction log backup file. These transaction log backup files should be stored for an appropriate period of time. A maintenance plan can be configured to automatically delete those files, you you can delete them manually or by some other scheduled method.
Generally, most sites keep things as simple as possible and that "appropriate period of time" would be until your next full backup. For example, if you are doing a full backup every Sunday, you will need to keep at least seven days of transaction log backups. (I'd keep eight days, I'd like a little bit of overlap just to be safe). If you only keep three days of transaction log backup files, you will not be able to fully restore your data once you get past Wednesday. In the simplest FULL strategy, in order to restore a database you need the last full database backup and all of the transaction log backups from the time the full database backup was taken until the time that you need to restore to. If you are taking full database backups on Sunday with a three-day lifetime on transaction log backup files, when it gets to be Friday you will be boned since the maintenance plan has deleted the transaction log backup files from Monday and Tuesday. You will only be able to restore the database using whatever was in the last full backup. I have seen people fall into that trap.
I'll close by saying that any person who is new to the way that SQL Server backup works should experiment/test restoring their database onto a spare machine, just to be sure that everything works the way you expect it to. You don't test a backup, you test a restore.