Just some very general thoughts for now.

Scene management is a critical part of organizing a game or simulation. It involves organizing the objects in a visual scene such that uninteresting ones (outside the view volume, occluded) can be easily culled. Collision detection algorithms can also often make use of this organization in similar ways.

In a typical 3D shooter, there are a lot of static objects, and it's worthwhile to spend computation time on arranging them in clever structures (e.g. BSP trees) that can be used to facilitate culling. However, updating moving objects in such structures can be expensive.

In a space simulation, we will work with vast variations in size, distance, and (depending on your model of distance over large distances) velocity. Some of the thoughts that arise in this context appear in the discussion of Hierarchical Coordinates. What that page is really talking about, I realize now, is Scene Management.

Unlike a planet-bound 3D shooter, there may not be much in the way of static objects. Luckily, even dynamic objects are relatively sparse in space, when looked at locally. The trick to culling objects in space is figuring out which ones are close enough, or large enough, or massive enough, or moving fast enough, to be of potential concern to the renderer and the physical simulator.

(Side note: This is not the sort of thing that is handled by a rendering system like Direct3D. It probably is within the purview of game engines like Torque. But I think that for a space simulation with a high degree of freedom of movement, like Independence War 2, stock engines won't have the right kind of scene management.)

Consider all the objects in a solar system. For a player in low orbit around a planet, a moon will likely be of interest to the renderer due to its size, but things in orbit around that moon probably won't.