This is a pretty good article - a lot of people don't realize that $scope.$watch is the most draining part of Angular performance-wise. It is easy to see the drain that it has by observing Batarang briefly.
I think it is possible to make most of these optimizations without bending the Angular source itself though. $scope.$watch returns an unregister function, so it should be relatively easy to unbind watches after they served their purpose.
Yes, we actually didn't modify any of the AngularJS source itself, but just overrode methods and inserted ourselves where we needed to. For example, we override $scope.$watch to intercept watch registration. However, we do rely on some of the non-public AngularJS functions to save us from duplicating a lot of code.. and that's where we push the edge.
It is an interesting idea to unregister the watcher when we do not wish it to be evaluated -- thanks for the suggestion. It would force us to recreate all of the child watchers again later, when we do need them to be evaluated again. We would have to investigate the performance implications.
We are already talking about other ways we could implement these directives by only relying on the public AngularJS calls in case there is enough interest and we want to publish the directives to the community at large. They might not be as performant, but wouldn't be broken by changes in AngularJS implementation.
I think it is possible to make most of these optimizations without bending the Angular source itself though. $scope.$watch returns an unregister function, so it should be relatively easy to unbind watches after they served their purpose.