Thanks for sharing your success story. I like that in the end you got a working solution that serves your users and your company well. That's what we do.
While I appreciate the result, I would have gone about it differently. From my perspective many of the efforts duplicated what SSIS does for us for free, namely the file parsing. Also worth noting, once you move file parsing into the database you gave up the option for doing data cleansing, validation, multi-system data enrichment, lots of things, in the SSIS space. I realize that sometimes we go with what we know, but SSIS was built to do this kind of work, and dynamically too. I think a lot of folks consider using tools other than T-SQL when the task seems to stretch the limits of what T-SQL should be doing, but when it gets to a point where they just need to get something done they revert to T-SQL because that is what is comfortable to them. Crutches like xp_cmdshell (as one poster mentioned, not your article) make it easier to do that as well and point to that type of thought process. I applaud your use of SSIS to at least avoid accessing the cmd prompt and file system from within T-SQL, something I never condone.
Here is a technical paper from Microsoft explaining how to do everything in SSIS:
I know not everyone will sign up for a pure SSIS solution but something along these lines is how I would have solved this problem. Granted, i have .NET development skills which are required for putting together the solution described in the paper and not a lot of DBAs do, nor is the technology a good choice in all shops because of that same fact. Someone has to support the code too, so that has to be considered as well.
There are no special teachers of virtue, because virtue is taught by the whole community.