No, the annotation doesn't impact performance.

The purpose of the annotation is to express intent to the static analysis tooling. In this case it lets the tool know that you defined the method in order to override (or implement) behavior from a supertype. If the supertype changes such that the method is no longer overriding the method it once was (for example, if the method was removed or renamed) then the tooling can let you know that your implementation might need to be updated in response to that change. Having the annotation helps the tooling find potential errors statically.

Yes, but why does the docs say we should use it judiciously?

That I don't know. In the analyzer package, and several other related packages, we use it liberally and have never seen any downside as a result of doing so.

We even go so far as to use the annotate_overrides lint (which is part of the pedantic rule set) to ensure that we don't miss adding the annotation anywhere where we could. That lint also lets us know if a supertype adds a method that happens to collide with one we'd already defined, which is also useful information for catching bugs.

cc @munificent

The override annotation, and its documentation, was introduced before package:meta existed, and there was no general consensus about whether you should use the annotation or not. That was in 2013. There still isn't consensus, but it's definitely tipping in one direction.

If we added the annotation today, the annotation would just have been added to package:meta. We considered moving it there for Dart 2.0, but decided that it would be too breaking, for too little benefit, but you should think of it as any other annotation from package:meta.

The documentation was written by someone who didn't feel strongly that it should be used everywhere it could (because it adds a lot of syntactic overhead and clutter for little perceived benefit), but you should only use it to detect breakage across boundaries where you don't control both ends. That's what the documentation states.

Use it if you judge that it brings you a benefit, and don't if you don't want to. The language, and the language style guide, does not recommend either direction, it's entirely up to you.

People have generally chosen to use it everywhere, so the documentation is probably a little outdated compared to actual current usage.