Compare for example, event sourcing. In that case, you keep a log of all actions taken, and determine the current state by replacing that log.
Here, you have an action that you want to take (order a pizza). But you can't just do that directly, because it's too simple. So instead you tell yourself "I currently have 0 pizzas" (the initial empty state file) and "I want to have one pizza" (your configuration), and you ask it "how do I get there from here".
And then after that is where the real trouble starts. You eat your pizza. You now have resource drift. If you try to correct that drift (does this provider even implement that?), terraform will think it needs to order you another pizza, because it still thinks you want to have one pizza. If you don't fix the drift, then next time you want a pizza you'll have to tell it that actually you want two pizzas. Because what you actually want is an action, but you have to work backwards from the current state (or rather, what terraform thinks the current state is) and what state to tell it you want in order to make it calculate they action.
All of which is more or less the opposite of event sourcing. Instead of wanting a state and having to apply a sequence of events to get that state, you want an event and have to calculate a sequence of state diffs that will produce that event.
I laughed...
> 8) As far as I know, there is no programmatic way to `destroy` an existing pizza. `terraform destroy` is implemented on the client side, by consuming the pizza.
10/10 infrastructure-as-code-based humor.