How does using packer and terraform in a CD pipeline compare to docker images built from git? At work we have a Go CD pipeline for producing docker images, and scheduling docker containers with rancher. 

This works quite well. You can commit a change to the Docker image in Git, the pipeline will pick it up, and upgrade the container. (The CD pipeline tags the version of the docker image with the build number of the pipeline, and this provides continuity throughout the upgrade.)

We have a similar arrangement with AWS AMIs using Hashicorp Packer and terraform. You can make a change to a packer json file in git, the pipeline will rebuild a new AMI.  Given the user's approval in Go (we have some stage-gates in Go) this can then in theory to stop the existing ec2 instance and start a new one based on the AMI that was built. (The ID of the AMI is passed through the pipeline.)

In practice terraform doesn't work quite as well in a pipeline. (Compared to docker). Sometimes it is just the sheer complexity of things associated with an EC2 instance and corresponding VPC/routing arrangements can tangle it. Sometimes it is that you need to custom-write your own tests to see if the EC2 instance was stopped, and then started. 

Is there a broader consensus on this issue? Are there some patterns I'm missing? Or is it just that when you're on the bleeding edge, things hurt a bit?

My question is: How does using packer and terraform in a CD pipeline compare to docker images built from git?
You're comparing apples with oranges according to your description. A strict comparison could be packer toward dockerfile, and/or terraform toward kubernetes yaml for example.

Main difference between your docker pipeline and your packer/terraform one is the architecture behind them.
What is putting the burden here is that your AWS infrastructure doesn't take advantage of auto-scaling groups rolling updates, or your 'stage-gates' in go does disrupt them.

You're not comparing docker with terraform, you're comparing rancher with your AWS infrastructure choices. If you don't use the equivalent bricks of rancher load balancing and deployment groups (kubernetes wording here) which are Elastic Load Balancers and Auto Scaling Groups in AWS you can't compare them.
That's saying a car and an bicycle does the same thing (transportation) with a better result for the car, put a motor on the bicycle and you'll have a far different appreciation and something less biased.

Your observation is pointing out that your usage of AWS facilities is sub optimal, terraform (or whatever provisionning system) can't help you more than running things, if your architecture is not made (in the terraform file) to allow rolling updates from this facility, no automatic system will fix it for you as you'll have to code it again (test instances status, etc.).

Of course rancher pre-bake most of those, making them invisible to you. This also mean you are enforced in rancher methodology (well, swarm, kubernetes or messos architecture to be exact).
That's the main difference, on one side you have an infrastructure already ready to serve with rancher and you can't run outside it, and on the other side you have to think your architecture before hand. If you were to run docker containers on a bare docker host (without any orchestrator on top) you'll end up with the same architecture design to think before hand and the same caveats you're seeing on AWS.

AWS is not strict on how you use it, it's an infrastructure as a service with no opinion on how you use it, whereas rancher enforce a bunch of services around your own container to save you the design time as long as you accept the constraint within it.

Hope this help seeing the problem from an upper level and as such I think the answer to your questions is that you were missing a pattern ;)

For the records: we're doing deployments on AWS with cloudformation (native version of terraform, with its own caveats) from  a push on a gitlab server and it works nicely, the work to get proper cloudformation templates and the script to run it was non negligible. This to say the tools are not the problem, it's all a design choice at a point, same results can be achieved, arncher comes with its own caveats and design choices to make when you integrate it into an existing infrastructure.