Здравствуйте...
Раз выбор есть, то действовать надо по ситуации...
Имейте в виду, что чем больше элементов в задании и больше потоков обработки, тем больше процессов операционной системы порождается для одного конкретного задания, что с учётом времени на утряску IPC приводит к увеличенному времени старта задания.

Если Staging используется в качестве корзины - можете в одно задание затолкать...
Например такую связку на каждый входной файл: Sequential File (читаем строку одним куском) -> Column Import -> DB
Можно Sequential File -> [Copy | Parallel Transformer (проверить, утрясти типы данных)] -> DB.
Если же нужны какие-то доп.преобразования, которые приводят к увеличению количества элементов для обработки одного входного файла - стоит подумать о разнесении по разным заданиям. Опять же - смотря как/чем данные заливать (bulk insert, loader-ы)...

По загрузке DWH разные подходы есть.
Если у вас ХД одни и те же таблицы заполняются из нескольких источников,тогда имеет смысл оформить загрузчики отдельными маленькими заданиями потаблично (Dataset -> [Copy | Tfm]) -> DB), сделать задания мультиинстанционными, чтобы с разными идентификаторами и параметрами можно было одновременно запускать из разных сиквенсов.

При заливке в DWH я обычно сразу в конечные таблицы не заливаю данные в любом случае, а приземляю их в Dataset-ы...
Почему? Ну потому задания работают, как конвейеры, и может так получиться, что часть данных в таблицу уже залилось, а на одной из последних строк вы словили ошибку, которая привела к аварийному завершению задания.
Тогда может так случится, что на основании полученной ошибки понимаешь, что то, что залито - тоже может быть грязно, и нужно очищать частично залитые данные... Редко, но бывает, меняются форматы входных данных, меняется источник - появляются какие-то неучтённые нюансы.
Если бы вы предварительно сохраняли в Dataset, то вычищать было бы ничего не нужно.

Кроме того, если сделать сложное задание по преобразованию данных (большое количество элементов, потребляемых ресурсов RAM/CPU) с прямой заливкой в базу, то в случае, если заливка будет подтормаживать от коннектора элементам назад пойдёт своеобразный сигнал обратной связи - притормозите, братцы, ну даже просто занятость ресурсов сервера на всём протяжении заливки - не есть хорошо.
Если задание потребляет много ресурсов сервера - другим заданиям остаётся меньше... =) Гораздо проще может быть выполнить быстро задание по преобразованию и положить подготовленные данные на диск, после чего задание завершается, освобождая ресурсы сервера, а маленький загрузчик уже читает подготовленный набор и заливает в базу.

Если найдутся те, кто скажет: "Ну как же, зачем на диск лишний раз укладывать? Лишний ввод/вывод..." , - ну, я же не прошу мельчить, а какие-то контрольные точки делать всё равно приходится, логика требует.

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

С DataStage нет абсолютных вариантов решения.
Его можно вертеть, как хочешь, выбирая то, что лучше подходит под конкретную задачу. =)
Пишите, пробуйте, поменять всё можно достаточно просто.