If you use Heroku for production, using it for CI too means that a lot of the annoying configuration pieces involved in getting CI to match production exactly disappear.

In my opinion CircleCI's configuration UX is actually really poor—compared to what it could be, and what Heroku provides.

In CircleCI, you're configuring against a moving target installation of binaries, and whenever CircleCI decides to upgrade Postgres or Redis or whatever, your tests start failing and you don't know why. Then you have to try to figure out how they've configured the services, and what it will take to use Postgres 9.5.3 instead of 9.6.1—big hassle.

Then there's the little UX things—in CircleCI you can't read the config vars you've set previously from the interface, which means you have to go through the super tedious process running a new build, SSH'ing into it, and then reading them from there, just to remember what user your Postgres connection URI uses.

On top of that CircleCI's documentation is much worse than Heroku's, so re-learning how to do all the random configuration things you need to do each time is more difficult than it could be.

I think anything that reduces time spent messing with CI servers is a big plus, because that work is usually the most frustrating work there is. $10/mo is nothing compared to wasting a day dealing with CI configuration every once in a while.