From this question and this answer, it seems that using expressions will cause the value to be evaluated from scratch every time. But I've searched the documentation and tutorials, and I haven't found a reference for this statement.
In my mind, both are wrapped in a $watch() and so when the $digest() cycle runs it will see whether the value inside ng-bind or {{}} has changed.
On performance, why is ng-bind better than {{}} as has been suggested, and where's the reference?
Details like this aren't always available in the documentation - you have to read the source. I took a peek and it seems that (as of 2014-11-24) they both work in a very similar way. Both cause a single directive to be instantiated to change the value when needed (the curly interpolation directive is generated on the fly).
Both directives evaluate the expressions involved on every $digest just like everything else. The main difference is that while ng-bind doesn't do any further processing on the value, with curlies, the entire interpolated text is recalculated on every digest. Essentially a string is built using $interpolate and that is compared with the previous value (this happens within the bowels of $digest). Neither way will update the DOM if the value (either the plain value with ng-bind or the interpolated result with curlies) hasn't changed.
To me the accepted answer on that question is a more compelling reason to use ng-bind, i.e. you can use it to prevent a visible flash of the template tags before Angular loads and compiles them, without resorting to hacks like ng-cloak.
Depending on variables there may also be cases where curly interpolation is actually more performant. One situation I can think of is when using ng-bind instead of interpolation requires you to create a lot of otherwise redundant <span> elements, and that tips the scales in the other direction. An interpolation expression also causes a single watcher to be created for the entire string independent of how many variables you use, as opposed to ng-bind which creates one watcher for each instance.
But as always, don't optimize for performance early, and if you do, profile to find out which part really matters.