You should think of readFile as the I/O input counterpart to printTasksToFile (you may even want to consider naming them more similarly like readTasksFromFile and printTasksToFile). Traditionally this usually means that its implementation should appear pretty similar but opposite to its I/O output counterpart.
You should consider making two constructors for the Task class. One that takes a single string (for constructing a Task from its quick add full length string) and one that takes the strings given one by one through the non-quick add option. This way the logic for parsing the data form the strings passed in from the quickadd option as well as the non-quick add option can all be moved to these constructors of the Task class, uncluttering the flow of logic here.

More importantly, you should just exactly reuse the behavior used to create tasks by the quick add option here when reading them in. Either create a method that does this and use it both in the reading in of Tasks from quickadd and from file, or use the constructor I proposed.
Anyway my point is this: This code does not successfully read in Tasks created whose task names are longer than a single word and reuse of code encapsulated in a method or constructor would prevent this.