Why does this happen?
There are three primary common areas capable of disagreement: the camera, the graphical model, and the physics. If there exists any disagreement between these systems about how time is advancing, there will be some visible jitter (or at least an inconsistency).
One common example of disagreement:
-Game.IsFixedTimeStep = false
-Each Game.Update uses Space.Update(dt) which takes as many steps of length Space.TimeStepSettings.TimeStepDuration as needed to reach the accumulated time
-Camera moves using dt
-Graphical model positioned using internal uninterpolated entity state
In the above, the internal entity state will sometimes not exactly match the progression expected by 'dt' because it cannot advance by fractions of a time step. So, the graphics using the uninterpolated data appear to jitter relative to the smooth camera motion.
The solution to the above problem is to use the InterpolatedStates, as you have done. However, there's a gotcha there: if an interpolated state is accessed through the entity's properties but the interpolated state buffer is not enabled, the access will fall through to the internal state. To fix this, set Space.BufferedStates.Enabled = true.
Another form of jitter arises when an unpredictable amount of temporal advancement occurs within any small time period, even if it averages out to a constant rate and even if there is no disagreement between different systems. Usually this is far less noticeable. Running a game with IsFixedTimeStep = true can cause this to happen, since sometimes it'll update more than once to 'catch up'.
I see that the Bepu physics space has a "TimeStepSettings" that we can assign to, but does it handle dynamic time steps by default?
The Space.TimeStepSettings.TimeStepDuration should be constant for the most part. Technically it could be changed each frame to allow for variable time steps, but that would harm stability.
In your demos file, I notice you have "IsFixedTimeStep" to false, yet my camera class has no jitter when used in there. Ideas as to why?
I would guess that it's because the demos also use the parameterless Space.Update() function. That version of the update advances by a single time step no matter what. The downside of doing this is that the physics update rate is coupled with frame rate. If frame rate is low in the demos, the physics run slow. This is convenient in the demos where sometimes I set up a wall composed of 80,000 boxes (or something equivalently goofy) for testing purposes; I don't want internal timestepping trying to keep up with real time in a simulation where I know it's impossible.
I'm implementing a different camera system than in the past and have found in certain 3rd person perspectives, I could see a lot of jitter in the behaviour of the model that I bound to my "CharacterController.Body.BufferedStates.InterpolatedStates.Position" (i.e. the model I draw to show where my character is). After viewing all search results with "jitter" here, I decided to set my game's "IsFixedTimeStep" property to true - voila, issue fixed.