To answer the second part of your query first, the decision to implement as a dataflow rather than use the T-SQL in a stored procedure or in a SQL task within SSIS is mainly legacy based. Although the ability to change the way the package works is far simpler in SSIS than having to trudge through the SQL. This will also make it easier for future developers to follow on and improve on existing flows within the package.
Maybe change SSIS task is simple and fast but you don’t forget about software development and ETL other tracks.
-Find impact changes
-Forward changes to test environment
-Multi user development
-Test changes (fe. blackbox test input – output)
-Debug and error handling
-Versioning
-Deployments task
-Logic for concurrent loading/ incidental loading…
… etc.
Maybe it’s only my opinion but TSQL rules !