I suppose you could do it if you had a very strict rule where absolutely everything that could affect a "unit" was inside its own directory (but never and nothing higher up than that "project root").
So you could check which sub-directory is affected within a commit and so on.
$ bazel query 'rdeps(//foo/my:target, //...)'
Of course, this query in the monorepo will take a long time or not work, because the target universe of "//..." is far too large. This is where other systems come in.
[0] https://docs.bazel.build/versions/master/query.html#rdeps
However by deriving from first principles, yes, there is no reason to re-query the transitive closure of unchanged targets' reverse deps, so caching can happen here.
For surface level changes this is often quite small. For changes to core libraries, well, you run a lot of tests.
It's usually quite nice though, and changes that break lots of projects are rolled back quite fast. Usually.
If there has not been any changes to your commit/cl and there is an already passing submit, it will just skip and submit.
At least in our project, each integration test has a certain amount of overhead. Some backends are fakes (when I request X, you provide Y), some are actually booted up with the test, e.g. persistence.
Multiply this across N integration tests, have lots of demand for the same CPUs, and you're up to 30-40 minutes of integration test time.
Though, that said, some integration tests can be crazy long if they have a lot of "waitFor" style conditions. "Do this, then wait for something to happen in backend Z. Once that's done, do this, and this, and this..."
But in theory with enough servers all the integration tests could be run in parallel. So it would only take as long as the longest single test.
Parallelizing tests has diminishing returns unless you manage to dramatically reduce the setup time.
Still, seems you could keep a handful of integration test environments always running? Time spent waiting your turn for one of them could well be less than time spent spinning up a whole bunch of servers.
I don't think all tests should be hermetic - the effort to make such things happen usually do not overweigh the time it takes to do them, but hey - that's what we are doing.
I find the larger factor is what kind of test has to run. Feature tests can take a while on CI if you're spinning up lots of embedded services (dependent services, MySQL, storage layers, etc).