I realize I didn't really give a very solid reason/example for doing such a thing. I certainly understand your point here.
With the risk of making this discussion more complex/confusing, one of the pain point of pipeline development is that it is not possible to copy individual steps with its configuration and reuse it. While most steps have very simple configuration where creating a new step and configuring it is feasible, those with far more configuration can be painful.
Still trying to keep this simple, let's say there is a step whose task is to generate some new fields based on other fields utilizing the lengthy configuration as a guide. This step also has a boolean configuration to trigger to "update" some stateful information (like a "batch number"). Upon initial usage in the pipeline, the "update" boolean would be false and just use the current value, but further down the line there may be a logic decision where the same step needs to be called to regenerate field values by having the "update" boolean set to "true" resulting in incrementing and updating the "batch number".
Creating the subsequent "update" step with all the complex configuration would be very painful just to change the "update" boolean from false to true. But having the configuration elsewhere allows for changing it once for all steps that are configured to use it without finding and changing all the steps.
Then consider if you need to change the complex configuration which requires to find all the places it is used in pipelines defined in the deployment.
Regardless, I have decided to put the information into an external database instead which will avoid having to be concerned about where the pipeline stage is running and ensuring synchronization of flat files across the instances.