The Pulumi/Terraform state contains more than a local copy of the last known actual state of your resources. It also contains information about the desired state is, which parts of the last known state were mutated by Pulumi/Terraform itself as opposed to external/unknown changes, etc. They are complementary.

Relying on that extra information you talk about sound like a liability more than anything else to me.

Why is there a need for anything else than a) the desired state (in the code) and b) the current state in the cloud?

The need for any extra state beyond that makes me dubious about the approach, fills me with fear and doubt about whether I really understand what the tool is doing, and so on. (I'm sure I can be wrong about this -- I'm just describing where I come from, and what I am seeking an answer to.)

Complexity always comes from state, why does one not try to have as little of it as possible...

You are correct that state is hard to manage, and consequently, the less state you have to manage, the better.

The developers of Terraform and Pulumi know this, but chose to make their tools stateful anyway. That's because if they were stateless, while they would certainly be less of a pain to manage, they would also not be as useful.

For example, without state, the tool wouldn't know what resources it has provisioned in the past. Consequently, it also wouldn't know what resources it can safely remove or modify.

Another example is that, without state, the tool cannot detect when a resource needs to be re-created from scratch, and when it simply needs to be renamed because the operator made a typo in the previous run.

In summary, yes state is hard, but sometimes you just need it to get the job done.