Yes. Bazel is half of the equation. The other half which other enterprises rely on is the server side of Bazel's Remote Build protocol. There, the scheduler can be implemented with logic that accounts for sandbox sizing as well as other requirements/constraints.
IMO it's a bad idea to tie your entire CI stack to a single build tool, no matter how good it is at building. It immediately puts on ceiling on what your CI stack can do, and for whom. You're essentially making the bet that 1) Bazel can build and test all the things with no exception; 2) you can convince, or force, 100% of your team to adopt Bazel for 100% of their builds and tests, in perpetuity; and 3) this drastic limitation on choice is the only way to make CI sufficiently fast and reliable.
I see how that bet makes sense from the point of view of a Bazel maximalists, and even more so from the point of view of a hosted Bazel vendor like BuildBuddy. But I can already tell you that it will not happen. Bazel is an amazing build tool, but on the testing side it doesn't offer anything that special. Tying yourself to it for tests is not worth the loss in flexibility.
I gave a talk about how we do it at BuildBuddy at a recent BazelCon here: https://youtu.be/iQqLtuBzkKE?t=848