Hate is a very strong claim. Nothing is perfect but in my experience all of the strong negative reactions were fundamentally attribution error where some combination of culture, limited technical depth, and poor architecture skills created a problem but it was politically appealing to say it was Terraform rather than, say, not reading a plan before destroying resources or building something far more complicated than the business needed.

In every case, the same people made the same mistakes with other tools. A common trait was that they [incorrectly] thought they were rock star developers and boring details like how their code actually runs were beneath them so they wasted huge amounts of time on deep module structures (or with CDK, elaborate TypeScript hierarchies) but resisted learning how the AWS resources they used actually worked.

I love Pulumi, but I can't in good conscience hand it to a group of developers when I know at least one of them will want to be extremely clever and abuse the fact that it runs real code to do cursed things that will make the code not just not idempotent (i.e. picking the most recent secret from somewhere, or a new AMI), but anti-idempotent (it doesn't run the second time around, it does things to the filesystem, it provisions things outside of the pulumi ecosystem).

Much easier to hand them Terraform and reject anything with local-exec provisioner, the official worst piece of terraform.

local-exec is like Rust’s unsafe: essential when you need it but something which should stick out in reviews to make sure it actually is needed.

We avoid it entirely. If it can't be done in Terraform, it must be done outside Terraform and fed in via variables.

Though of course there's also teams that run ansible from it with lots of implicit settings, making it a pain to move from dev machines to CI.

I mean, everyone who uses any could infra tool ends up hating it for some reason or another, there's nothing close to perfection in that realm!