There are a number of use cases that require the ability to define branches as being interesting as well as the ability to define specific revisions as being interesting

The general idea is that when a branch or revision is not interesting (or if interesting is a scalar rather than a boolean then if the interesting scalar is less than some cut-off) then branch-api would not automatically build the branch / revision. The Build button would still be available from within the Jenkins UI so that users could still manually request builds, but Jenkins would only automatically build the interesting things (and if interesting is a scalar it could even prioritise building more interesting things first) 

• Some people would like to discover origin branches and origin PRs, when the origin PR is created from the origin branch - for example when the origin branch is a long lived branch and they use periodic pull requests to review synchronization between branches - then they would want the origin branch job to be retained... but that origin branch job (which is effectively building PR-head) is not as interesting as the PR-merge branch job.

Currently, you could prevent building the branch twice (or three times if building PR-merge and PR-head) by only discovering origin branches that are not also filed as PRs... but in that case you are relying on the orphaned branch strategy not deleting your origin branch before merging the PR.

With the concept of interesting branches we could say that the origin branch is not as interesting as the PR-merge or the PR-head branches.

• Adding Tag support will be easier if we consider old Tags as non-interesting by default. Whether new tags are considered interesting would be something that users could configure using traits.

Another use case is where people want to prevent automatic building of revisions until specific criteria have been met:

• Only automatically build revisions that have been flagged as OK to build. This is somewhat similar to trusted revisions, but a different concern as you could have interesting but not trusted as well as trusted but not interesting.

• Flag specific revisions as non-interesting based on the commit comment or perhaps even based on the files modified

This is not an exhaustive list of the utility of the "interesting" concept.