I've spent a bit of time recently with Quartz.NET, and I can share some of the experiences we had. My scenario covered a single process (windows service) that was responsible for updating the existing schedule (using details downloaded as XML from a server). The service process also covered most of the functionality that could be triggered.
I think the key factor here is what you mean by "updating" a task. Do you mean simply altering scheduling details (what tasks to run, when to run them etc), or the actual binaries involved in executing the task? If you're expecting frequent updates to binaries and features, then a single monolithic model is probably not right for you. If you are only expecting frequent updates to when and what task should run, then it's worth centralizing the management of the tasks and scheduling.
Trigger groups work nicely for dividing up and managing various job types. This makes the CRUD against the in memory schedule much cleaner. For example, you can get all the jobs in a group fairly easily