What I've noticed happens a lot with both constraints and body movers is instability from over-correction when frame rates drop. Basically, you have a system that is using a force to try to keep something in equilibrium, and the magnitude of the force is tuned for 60 FPS. Then, frame rate drops, and because of the longer time between frames, the force gets applied for much longer than intended: double, triple duration, or worse. The end result is that the force doesn't bring the system back to equilibrium, it overshoots. Now you have an oscillator. If you overshoot by more than the correction you were trying to make, you can have an unstable system that gets worse with every frame, exponentially. This often results in things flying dramatically out of the world. But weirder things can happen, especially when you have high forces but also strong damping. You can get quasi-stable behaviors. Things flipping around seemingly randomly, or levitating are both easily reproduced. I observed this the other day in the Race template, when I added too many Jeeps. I got flipping and flying Jeeps, and Jeeps that were driving OK apart from an occasional spontaneous 360-degree roll around some strange axis.
The easiest way to get into trouble, without scripting, is to use arbitrarily large maximum forces, torques, and power on body movers and constraints. It's pretty easy to make something that goes unstable with a slight drop in frame rate. Using scripts that set forces and don't account for time between frames is also a bit risky. I use BodyForce objects in my character controller, and I have to carefully manage the forces, compensating for frame rate drops. I also do sanity checks using the typical Newtonian motion equations for position, velocity, acceleration, etc. that games have always done. If you know where something is supposed to end up, from a simple and cheap calculation, you can catch an overcorrection in one frame and not let it oscillate out of control.