Okay I've thought about this some more.

I don't think that the classpath is sufficient to solve the problem we are solving here. 

This is actually more than just an optimization; We're trying to find the relevant scope of the search. It's true that if we have the cursor at a method definition this will effectively mean that we're finding all the projects that could potentially reference the method. However, an equally likely use case is that you place the cursor at a method invocation and want to find all "other" references, in that case how do you set the scope of the search? Currently we set the scope to all projects that are connected to this one. Other options could've been the entire workspace, or the current working set. I feel that the current solution is better than using the workspace or working set. Here's an example set-up (taken from my test):

```
    (A)        (E)
    / \
   /   \
 (B)––>(C)
        |
        |
       (D)
```  
A has no dependencies
B depends on A and C
C depends on A
D depends on C
E has no dependencies

In this case, if we use 'find reference' in A,B,C or D it'll search in all projects except for E as it's not connected to the current set of projects. If we're just using the classpath we can find all the projects (and libraries) this project depends on by we can't find all the projects that depend on this (without having to check the classpath of every project in the workspace)