A lot of people including myself have used tools to generate CF or Heat templates in the absence of a need for cross-cloud compatibility that Terraform offers. You can use Troposphere, Stacker, or anything else that can intelligently generate and manage component information as a JSON or Yaml file and get much of the power of Terraform - perhaps more given the option of a full language rather than an external, declarative DSL. I still haven't found an idiomatic, elegant API that can manage all those template references.
The primary advantage Cloudformation has for myself is a lack of need to manage the state that Terraform spends so much effort upon. In fact, Cloudformation does this fairly opaquely but was much more obvious when I tried to deploy a CF stack when S3 was down a while ago - being able to use an alternate state file location would have been handy then.
In fact our very own jdreaver wrote a Haskell EDSL for generating CloudFormation templates, this seems to be not uncommon among companies who want to do infrastructure as code with that ecosystem: https://github.com/frontrowed/stratosphere
Unfortunately when you inevitably make changes to your CF config, `terraform plan` doesn't help because it's likely you changed something inside the `template_body` and Terraform just knows the string has changed and doesn't tell you what part of the config changed. Parameterising as much as you can helps.
The primary advantage Cloudformation has for myself is a lack of need to manage the state that Terraform spends so much effort upon. In fact, Cloudformation does this fairly opaquely but was much more obvious when I tried to deploy a CF stack when S3 was down a while ago - being able to use an alternate state file location would have been handy then.