If your use case is actually simple, you can declare a big activity (what is cheaper, as you stated), but in general the benefits of using a set of small activities are:
- You can run a particular step (one of these activities) in a different set of workers (via a different task list), with specialized resources. For instance, you could run two farm of workers: one "regular" farm for general purposes, and one "Big CPU" farm for computing-intensive operations; all part of the same workflow execution.
- Depending on how you execute activities (using Flow or your own worker runtime), you could retry failed activities separately.
- You could version your activities independently, instead of just one version for the whole workflow.
- If the workflow evolves, it would be easier to extend or update using a set of activities (one of the building blocks of your workflow).
- If in the future you need to act after a workflow signal, you would have a hard time decoupling your logic to support it.
- Atomic activities are potentially reusable by other workflow types (or even the same workflow: for instance, sending an email at the beginning and the end of the workflow).