1. Measuring code complexity. I've often felt that code complexity can be gauged several ways, and one is the number of "if" statements (or select..case). Being able to query the code base of an extremely large solution is a big step in that direction.
2. Being able to "query" the call stack - how do I get from this line to the base constructor of my "user" object. Rather than stepping through the debugger, it could be a query of the code base to find the path from here to there.
3. Detecting bit-rot. Finding any method class that's simply never used could be another "query" of the code base. Yes, proper test-coverage would help detect this, but not every production system has unit tests.
4. I've worked on projects in the past where we really wanted to add guid tracing to the preamble of each function to dynamically trace the code at run time. If Roslyn supports "update" queries of the code, it might be easy to add such a feature across the whole code base (or perhaps only classes that inherit from some known base class).
Managing a code base like this (rather than grepping/searching) is a powerful concept. Perhaps we could see a LINQ for source code some day?