From a cursory overview, it looks like Terraform is basically LIKE a CloudFormation type abstraction. Ansible contains declarative models for lots of cloud providers as well, but does not attempt to abstract out the different clouds. We generally view wanting to show things in their natural state (figuring you will know you want to use feature X or Y, and want the knobs/buttons exposed).
But yes, we have similar features for saying "X instances of this should be running now", make it so, all that don't require use of CloudFormation.
For people that like Terraforms flavor though, I can see users using these tools together. They could declare a cloud using either ansible or terraform, and then use ansible for the final configuration and application deployment, plus full lifecycle management.
I know things like Packer like to walk people down a more imagey road, but you can also use config tools to describe the recipes that build your images, and that would include Ansible, Puppet, Chef, or even (if you so wished) bash.
I'm not a fan of bash though :)
I'm happy to see more efforts to make cloud provisioning accessible though, and like the idea that this would allow more easy migration between some cloud providers. Ansible has a lot of the same declarative thingies, but will probably appeal more to people who aren't looking for the DSL.
http://docs.ansible.com/list_of_cloud_modules.html
It doesn't look like Terraform is attempting to be a provisioner itself, so it wouldn't do the things that Ansible or other config/app deploy tools do once you have a running instance, but does some of the things various config tools do to help you GET a running instance.
One of the things shown in the Ansible examples are how to do a cloud deploy in one hop, i.e. request resources and also configure the stack all the way to the end, from one button press, and can also be used to orchestrate the rolling updates of those machines, working with the cloud load balancers and so on, throughout their entire life cycle -- all using just the one tool.
As for where the future of this tool is, I obviously can't speculate, nor should I. But I do welcome more attempts to simplify beasts like the AWS EC2 API space, because I think we both agree nobody wants to really keep all of that in their head at all times.