Functionality already exists for Activating/Deactivating Triggers through a task.

The usefulness of being able to create a trigger from scratch through a job is as follows.

Job:
In my case, a Job is being activated by a file trigger.
The Job uploads the file that activated the trigger to an SFTP server. (Ex. Test.csv)
The SFTP server processes the file and generates a result file with the same file name, but a different extension. (Text.csv -> Test.res)
The Job attempts to download Test.res until it is successful.

Other tasks are included for proper file keeping.

Overall this Job typically takes ~4 minutes.
At times, the back-log of files waiting to be processed grows upwards of 300 files.
Thus creating a back-log of ~20 hours worth of file processing.

Here is where trigger creation through a task would be of great use.

A first Job would follow the same process as the original up through the SFTP Upload.
Afterwards, a task would create a trigger on a second job.
This trigger would be a remote file trigger looking specifically for the file that was uploaded with instead the .res extension.

The second Job would be triggered by any of the files that have been processed and whose results have been created on the SFTP server. The triggers would add runs to a queue.

This would change a singular ~4 minute Job into a 4 second Job (plus the time a trigger creation task would take) and a 10 second Job.

With the same 300 files. All the files would be uploaded in ~20 minutes. And all the files could be downloaded in as fast as 50 minutes.

I would still be at the mercy of the SFTP's file processing, but the SFTP server is only processing one file at a time.
Files on my end could be waiting up to 20 hours to even be uploaded currently.