I think that there are some points that we can argue about.
I’m not sure if it affects the performance depending on where those files are. If somehow the files that you would invoke to the main workflow are placed in a location that may need some firewall rules to be reached, this could possibly affect the performance.
Also, when you publish a project on orchestrator, you create a nuget package, so all your assemblies present in the currently project are loaded to the package. Now, I’m not an expert at all on this point, but I think, and this is just me guessing, that it may take a little extra time when execute the package if your main flow would be calling a flow outside program.
If it is true, would be this extra time meaningful to create a fuss over it? I don’t think so.
However, there are some others, and in my opinion, more important points on this.
Compliance, Securety and unnecessary work.
Suppose that you work with some version control tool, like Git, for example. Once you upload the code to repository, you will not be able to validate all the code that it is present on that project. So if you need to validate the code and put it in production, you will to guess that there is a flow not present on that repository, search for that wherever it is and validate it a part from all the rest of the code.
Besides that, once you publish to repo, you are to see every change that someone would make on that project. But, if you a have a separated flow, how would you now if something changes?
Imagine if you publish your project on production env and someone changes the separated flow. I can think in a bunch of problems that this would cause, starting from a broken robot to a harmful script executed on the robot machine.
As i said, in my opinion, the performance factor is the least of your problems. If you’ll need to use the same flow in more than project, you should create a library instead. But leaving a flow where someone can access and change it, and this would affect the production env, that is something i definitely not recommend doing.