The reason is that workflows are inherently imperative.

Configuration formats work well for domains where declarative programming makes sense. For example, Terraform defines "what should be done" instead of how it should be done. Some workflows can be described using declarative syntax. But these belong to some specific domain. In this context, Terraform HCL can be seen as a workflow definition language for infrastructure deployment.

Temporal/Cadence are targeting nondomain specific workflows, so they have to be imperative. And I strongly believe that JSON/YAML/XML/etc. are awful languages for writing imperative programs. They add no value but introduce immense complexity. And they almost always embed some expression language for condition and other evaluations.

For imperative programming, any general-purpose programming language beats heads down any configuration based language in clarity and other features like IDE support, debugging, unit-testing, mocking. We have software systems built form millions of lines of code, and people still make sense out of them. Just imagine Linux kernel written in JSON instead of C.

Note that some workflow engines define workflows as code as well. Airflow is a notable example of this approach. Note that Airflow uses code to define DAG. But the actual execution engine executes the DAG and not code.

Temporal executes the workflow code in a general-purpose programming language directly without any intermediate conversion to AST/DAG or similar.

Then the question is, what makes Temporal workflow code a workflow? Is any code a workflow? Temporal makes workflow state, including local variables and thread stacks fully fault-tolerant. It is like having a computer with a fully durable RAM. Actually, Temporal provides even stronger reliability as a workflow code is not linked to a single computer is automatically migrated between computers or even different clusters when infra failures (or just new code deployments) happen.

I would recommend checking out the documentation (https://docs.temporal.io/docs/overview) and samples (https://github.com/temporalio/java-samples, https://github.com/temporalio/go-samples) to see it for yourself.

> Temporal/Cadence are targeting nondomain specific workflows, so they have to be imperative.

I'm not sure that follows, although it's interesting! BPMN, for example, is a declarative way of defining processes that isn't domain specific. Did you have a look at that?

BPMN is not declarative. It is imperative. It doesn't say what should be achieved. It gives exact instruction what should be executed and in which order. And a big chunk of those instructions are not really visible in the diagram. For example which parameters each activity takes or shared state updates are hidden.

So it has all the issues that I pointed out above.