Accurate prediction of relative formation position in LEO

Yes and no.
Yes because if you do a full long range propagation on both satellites, they can loose synchronization on intermediate steps because each integrator bases its step control decision on an estimate of the current error, which is based on the current state. Since the states will be different for the two satellites, error estimation will be different too.
No because if you don’t care about the intermediate steps and just use the result of the propagate method at final time tt, then you have already fixed this time by yourself independently of underlying integrator choices.

This leads me to one advice: don’t do the propagation loop as you did, by setting a series of time and calling the propagator in a loop, in particular if your various times tt are regularly spaced (resulting from t = [initialDate.shiftedBy(float(dt)) for dt in np.arange(0, duration, step_time)]). This is really not efficient, in particular with a 0.4s long propagation. You should rather perform a single propagation for the full duration (5650s in your case), and register a step handler to the propagator that will be called every step_time. With these settings, you let the integrator choose step sized that may be far larger than 0.4s (you have set a max step to 10s, but I would even suggest to let it go to 120s or more, as the real size will really be driven by the positionTolerance). The sampling time at which your handler will be called (here step_time) is completely independent of the step the integrator uses for its computation, the integrator knows how to interpolate within the step using its own internal model, which will be consistent with the dynamics since it is really the model the integrator itself uses.

As you want to have several satellites propagated at once, you will need to use PropagatorParallelizer, together with a MultiSatFixedStepHandler. Beware however that the fixed step handler for propagator parallelizer is a new feature introduced in Orekit 12.0, that should be released probably tomorrow, and the Python wrapper will be published soon after (see [VOTE] Releasing Orekit 12.0 from release candidate 2 - #13 by petrus.hyvonen).