Use whatever tool you like: SQL, Rust, carrier-pigeon - but it wont be a panacea to solving cloud infrastructure.
it makes it much more easy to reason about things, as state is abstracted away.
- Opening a YAML file in a text editor, deleting some lines, then doing a Kubernetes or Terraform or whatever apply operation
- Creating a SQL migration to delete some rows from a table, checking the migration into the repo, and then running a database migration
?
Now the real magic, would be to make changes atomic!
There are also dependencies within the resources to consider, such as network creation before firewall rule before VM
It would be very difficult to mess this up with SQL foreign keys.
At the same time this SQL would be useful when used in combination with a classic database migration framework which essentially comes down to a bad version of terraform.
Inversely, you could simply use de Terraform CDK and an SQL adapter to write SQL into Terraform definitions. People who want to use SQL can use that, and in the background it's still terraform with all its benefits.
The nice thing is that adapters to sql engines often have exactly the sort of protections you want baked in, e.g. "check to make sure the updated at timestamps match before committing an update"
What infrastructure management tool do _you_ prefer then?
So Terraform and Ansible come to mind. Both deeply flawed, but they become the least-worst current option.
People should still strive for better, test new ideas with new tools, but choices for production code should play it safe almost every time.