cl_threadedphysics predates csqc and does not play nicely with it. in order to do so, it would need to invoke csqc on a different thread, but the qcvm is inherently unthreadable (self, temps, locals, etc). the default has always been 0 and it doesn't appear in any menus. the current intended behaviour is for csqc to no longer receive CSQC_InputFrame calls when this cvar is active (DP lacks these calls too), but it also doesn't get tested much.
cl_loopbackprotocol controls the protocol used to connect the internal client to its internal server. when using my purecsqc mod the internal server is not meant to be in use at all (do NOT use the map command - purecsqc registers a csmap command that should be used instead), so this cvar will affect absolutely nothing in the specific case that you state.
recent builds have focused on emulating DP's csqc a little better, primarily in order to run xonotic (requires a new default.cfg as well as a few other xonotic-specific fixups, so don't expect it to work out of the box without those).
probably I broke something in the wrong bit of code while trying to work around xonotic's flawed prediction logic (which is a bit of a nightmare tbh). if its flickering exactly every 1 in 64 frames then that'd probably be a simple off-by-one issue... other frequencies would be race conditions...