Yes, you could import the data to a staging table. But if neither the source nor destination is SQL, the overhead of creating the table and cleaning up the table and possibly two extra hits to the network bandwidth to copy the data may not be justified for something even a lowly laptop could easily handle by itself.

Let me try a counter example. A co-worker once showed me an SSIS package he was very proud of. It had a huge data flow with conditional split and derived column transformations. It was a work of art, but it could also have been done in the source SQL statement with some CASE statements and subqueries, and probably with less development time. The whole data flow could be reduced to an INSERT/SELECT statement in a SQL task, without dragging the data over the network twice so it can be handled one row at a time in an SSIS data flow. It was a valid solution, and might be good for some kinds of non-relational data sources, but in this case it was not the best solution.

My whole point was that often the questions of data source, destination, and possibly volume should take precedence over what language the solution is implemented in. For all we know the data is coming from a web service and is to be reformatted in XML and sent to an FTP site. I would certainly go with the T-SQL string splitter if the data source is SQL Server, but I would want to get that pinned down before I started debating which T-SQL string splitter implementation to use.