Sure, just manage two tables of bodies as we discussed earlier, one with massive bodies and one with mobile bodies (some bodies might be in both tables). The first loop should work on the massive bodies and the second should work on the mobile bodies. Or if you really don't want some bodies moving (stars?), make them static and skip static bodies in the loop. Or if you want bodies to go to sleep when you fling them off into space, you could query the viewport for fixtures to work and let damping get them (I think this would work, not sure), but it's weird for things to slow down and go to sleep when you fling them into space, so you might as well delete them.
If a good deal of the bodies that would otherwise be sleeping are now moving very gradually, wouldn't it result in a lot more calculations
Specifically, my first solution was O(n^2), meaning n-squared "units of work" need to be done to process n bodies (exponential time complexity). Ivan's solution was O((n^2+n)/2) I believe; the number of units of work to process n bodies would be the nth triangular number (better than exponential). My second solution is O(n), meaning only one unit of work per body (linear complexity), which is I think as good as you can hope for with this kind of thing.
I get that you're asking if box2d will have to do more calculations, but I wanted to address time complexity first. If Ivan's solution can support 300 bodies (for example), then my original solution will only support about 200, but the linear solution should support 45000 (all other things being equal, and aside from any limits in box2d). The details of what G is and where the bodies list come from were just meant as an example. You might want to come up with G by scaling the real G by your world scale (as in planets are 10 million times bigger than 0.1 to 10 meters) and by your time scale (you don't want to wait a month for a moon to go around a planet), or just mess with it until it looks right.