Here are the impressions I formed, please DO jump in with corrections.

Terraform's strength is to set up everything the user wants in a cloud
outside the virtual machine images.  Terraform is more powerful than
cloud brand tools and uniform across cloud service brands.

Mutate or audit inside the virtual machine images is not terraform's
strength and should be done by something else.

An advantage terraform has over a web dashboard "make a Linux web
server" button is that terraform can be scripted without screen-
scraping.  Another advantage is terraform can build more complex setups.

There is no way for users to tell in detail what terraform is going to
do, without actually spending money and letting it manipulate a cloud
service.  We have to pass the bill to know what's in it.  The
terraform-costing estimator starts to crack this nut.  Doesn't the
output bottleneck down into a set of cloud service provider commands?
I assume the terraform developers can tell what the output is, and
they should expose or advertise that functionality.

There is enough fine-grained indirection that a setup with a 1% change
can be built alongside the old production one.

Terraform can create and delete, but can't mutate or audit.

Can't mutate: given two sets of terraform code which differ textually
by 1%, terraform can't mutate the old cloud setup into the new setup.
However, underlying cloud administration features may not reasonably
support automatic mutation, like cisco router configurations in the
1990's.  You could replace the whole cisco config, but you couldn't
alter one config into another without human understanding of how far
up the config menu tree to climb to back out a detail and re-make it.

Can't audit: given one set of terraform code, it can't tell if an
existing cloud setup matches it.  I could and did diff cisco router

Working Version                 Brian Bartholomew, President         Host Factory computer configuration management