ワークフロー（xamlファイル）を分けられる理由
ワークフローを分けられる理由は改めて説明するまでも無いでしょう。
「ワークフローを再利用するため」ですね。
再利用性や修正のしやすさを考えずにワークフローを作ってしまい、後で困るといったパターンをよく見かけます。
そういったワークフローは将来的に負債として扱われてしまいます。
「うわ、あのワークフローか。。。修正めんどくさいな。」と後継の方に言われることでしょう。
どう分割したらいいの？
単一責任の原則に従って分割できていれば、まずまずだと思います。
単一責任の原則はオブジェクト指向言語の原則ですが、UiPath向けに解釈するとこうなります。
「1つのワークフローは1つだけの責任を持つ。すなわち、ソフトウェアの仕様の一部分を変更したときには、それにより影響を受ける仕様は、そのワークフローの仕様でなければならない。」
もう少しだけ分かりやすく説明します。
1つのxamlファイル内でAサイトとBサイトの2つのサイトを操作しているとします。
Aサイトが改修されたとき、そのxamlファイルを修正します。
Bサイトが改修されたとき、そのxamlファイルを修正します。
AサイトとBサイトは、それぞれ独立しているのに片方が改修されたら同じxamlファイルを修正しています。
つまり、2つの責任をそのxamlファイルは持っているということです。
Aサイトを操作したいなら、Aサイトだけを操作するxamlファイルを作る。
Bサイトを操作したいなら、Bサイトだけを操作するxamlファイルを作る。
といった具合に、責任を分けてあげることが大事です。
「これもあれもそれも俺に任せろ！」といったワークフローを作るのではなく、
「俺はこれだけしかできないぜ！」というワークフローを作れということです。
そうすることで、「えーと、要件がこう変わったから、、、このファイルを修正すればいいのか。」と簡単に修正対象のファイルを見つけることができます。
ただ、注意しなければいけないことがあります。
「同じ責任を複数のワークフローに持たせるな。」です。
ログイン処理の一部が変わっただけなのに、「このファイルと、このファイルと、あのファイルも修正が必要だな。」なんてことになると分割するだけ損になります。