I think we could remove this now? The only place this is used is within the post load process to ensure we don't duplicate any references in the scene. This can probably be removed.
pushToPrim when enabled, does not add transform operations into the UsdPrim it is tracking. So for example, if you have a prim with no transform ops, not much is going to happen. If however your prim has the full spectrum of rotate axis, translate, scale, rotate, shear, etc; then you will be able to have full control over the prim. This will need to be addressed at some point soon. One of the more challenging aspects here is that we will need to modify a) the geom op order [e.g. insert a scale op, where there was not one before]; and b) rotation is going to be a PITA [There may be a rotateX op, but after modification that may need to be deleted, and replaced with a rotateXYZ op]
If pushToPrim is disabled, any modifications to the transform values are stored as offsets from the USD prim values. This works quite well for local space operations such as scale and rotation, semi-works for translation [effectively this is a parent space translation offset - useful for moving an anim clip] However for values such as rotation and scale pivots, yeah, the result might be a little strange.
I'm not convinced the way that I've organised compute and validateAndSetValue is ideal. It works, but if anyone has some improvements to suggest, I'm all ears.
Generally speaking, when localTranslateOffset is (0,0,0), then the translate/rotate/scale tools work quite well. If however localTranslateOffset is not (0,0,0), then the behaviour of the rotate tool is a little odd. Really this should be taken into account within the AL::usdmaya::nodes::TransformationMatrix::rotateBy and AL::usdmaya::nodes::TransformationMatrix::rotateTo methods.
1.8.7 
