Since you asked... 🙂

You can't change the metadata of a target CSV Connection at runtime, at least not without third party tools or completely rolling your own script component to do this. So, while this child package will work fine in this particular instance, it's not a re-usable child for another process unless the output CSV is exactly the same. This comes back to the concern of over-coding a solution, at least to me. What benefit is the child package vs. just having it contained within a single parent package?

When I work with SSIS, I typically look at logical breakpoints, not code breakpoints, as to when to move to a new SSIS package. This has more to do with job restarts due to network breakdowns (or other random issues) at a particular step in a series than for code encapsulation.

If you're looking to encapsulate a step series for testing runs (For example, a truncate-load on a particular table without running an entire package) the sequence container allows not only for collapsable organization of multiple code pieces, but rt-clicking on it allows you to execute a container for testing. Very useful.

My general concern with Child Packages is not that they can be fussy to work with, it's that they segregate sections of a process usually with little purpose. As an example, you're called at 2 AM by your DBAs (you're a dev) and your package broke. They send you a lovely .log file and the DTSX package from production (because never trust dev still looks like that) and you crack it open and get to work. You eventually find out the problem is in the child package and now you have to track down the guy on call (hopefully he's not asleep again) and get yet another package offloaded and shipped to you. End of the world? Absolutely not. Annoyance with little to no gain? Usually.