SemmleCode gives access to mostly inter-procedural information, such as classes, methods, fields. I would be interested in more intra-procedural information, such as local variables and the assignments between them. For example, such information would make it possible to express a points-to analysis to the runtime types of objects from allocation site to everywhere they're used. (I'm sure you never expected me to want a points-to analysis  )

The most distinguishing characteristic of Jimple compared to many other Java IRs is that every variable is given a static type. This is often convenient, but has costs. Computing these types is NP-hard. Considering the hardness of the problem, the algorithm used in Soot [Gagnon, Hendren, Marceau, SAS 2000] is quite fast for typical cases, but can still be a bottleneck when processing many classes. Another issue is how it behaves when the whole program (or at least its entire class hierarchy) is not available: I have not managed to understand how an incomplete hierarchy affects the algorithm, even after discussions with Etienne.

Another difference is that many IRs are in SSA form. Jimple is not, but Shimple is an SSA version of Jimple. For a query tool, SSA would be convenient, I think (without it, one would have to write some reaching-defs subqueries).

If the type inference was done on SSA form, would it still be NP-hard? This would be an interesting question to answer...

My recommendation would be to start with an SSA-based form without the Jimple type inference first. A typed IR could be built on top of it later, either built into the Semmle engine, or perhaps expressed using SemmleCode.