Расширяемая Windows служба

1. Кому лучше дать ответственность за выполнение задания по расписанию самой службе или объекту задания?

Если все расширения являются заданиями, то имеет смысл вынести код планировщика выполнения заданий в основную службу, хотя-бы для того, чтобы не дублировать его в каждом расширении.

2. Правильно ли вынести конфигурацию заданий в отдельный XML файл, а в app.config хранить адрес этого файла, а потом его передавать в конструкторы нужного задания, что бы объект сам себя искал там и конфигурировал?

Я бы сделал хранение настроек отдельными файлами для каждого задания в фиксированной папке или БД и передавал параметры в конструктор. Но можно использовать и ваш вариант. В любом случае, расширение должно уметь обрабатывать ситуацию, когда оно добавлено, но конфигурация отсутствует.

3. Можно ли будет на ходу заменять библиотеки расширений(например, на обновленную версию) без отключения или мне не дадут заменить, используемые библиотеки?

Загруженная в CLR сборка может быть выгружена только вместе с доменом, в который загружена. Это решается загрузкой сборок-расширений в отдельный AppDomain, и выгрузкой этого изолированного домена, перед удалением DLL. Вообще про этот механизм лучше отдельный вопрос задать, там много нюансов, которые нужно учитывать.

4. Имеет ли смысл использовать MEF?

Да, этот механизм именно для таких случаев и предназначен