Some of the things I like about it are that it allows me to have multiple environments (Prod, Dev, QA, etc.) where each stack can be slightly different but still related. It also has global variables (ie. office IP address) that allow you to change something in one place and have it be updated everywhere. Finally, AWS resources are defined in Handlebars partials it's easy to add new ones or maintain existing ones as AWS adds more functionality.
It's still a work in progress and I updated it almost every week. If you like working with NodeJS I'm always looking for help. :)
Given the inputs you stated, I am full CF because I don't want to manage state files, and I want some more advanced things like Deletion policies and automatic tagging of resources with the stack info. We use these tags in a lot of lookup scripts when operating on the infrastructure.
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.