В самом деле? Можете раскрыть тему этого избегания подробнее?

Ничего не понял.
Почему данные из потока нельзя вычитывать проще - средствами СУБД (всякими курсорами, циклами, сервис брокерами, CLR, OLE, etc)? И почему поток данных надо вставлять без Bulk insert, искусственно тормозя работу?

Есть оператор bulk insert, загружающий данные из внешнего файла, и есть bulk operation внутри Destination SSIS (включаемая опцией Fast Load). Автор темы, очевидно, имел в виду последнее.
Интересный вопрос, похоже, что Вы SSIS в глаза не видели, иначе бы эту чепуху не писали.Ваш ответ на мой вопрос кажется мне совершенно неинтересным гаданием по юзерпику. Не только неинтересным, но еще и неудачным.

Лично я могу легко объяснить, почему я работаю с потоками данных через SSIS, а не через СУБД - потому что это выходит быстрее. И если я не стану использовать Bulk InsertFast Load, то вся выгода будет потеряна на этапе вставки в БД (собственно, я даже с Fast Load упираюсь в дисковый массив) .

Я знаком с таким предрассудком со стороны программистов БД, представляющими средства ЕТЛ исключительно как гуевый дблинк. Я его даже отчасти разделял - примерно 10-15 лет назад.

P.S. Лично я для своих задач считаю прослойкой именно СУБД. Все нужные данные должны быть в памяти процесса, а не где-то там...

Не-не-не, все совсем не так. Есть потребители данных, которые читают БД, а есть средство ЕТЛ, которому для работы нужна малая часть столбцов - ключи-идентификаторы (для их разрешения), хеш, версия. В 50Гб эта малая часть более-менее влезает, а что не влезает, то можно разбить на секции и подкачивать из БД по требованию. В результате ЕТЛ практически не занимает ресурсов основного сервера (кроме момента инициализации) и качает в него данные практически онлайн.