Nodes between constraint objects and their bones?

In my game rigs, I generally have been rigging my FK joints like this:

control_object -> orient_constraint (with offset) -> bone_object

recently I followed a tutorial where bone_object was orient constrained to a child node of the controller.
The child was an additional ‘dummy’ transform node, oriented to the bone:

control_object(parent).transform_node(child) -> orient_constraint (no offset) -> bone_object

The tutor only briefly states that this is for “clean” constraints: no offsets needed.
Other than eliminating the need for an offset, is there some advantage to this ?

normally i do it like this:
empty group oriented to the bone(parent).control with zero rotations(child) -> orient_constraint (no offset) -> bone_object
gives the same result but then the controller follows the same orientation as the bone itself.

the dummy transform is new to me and i don’t see why it is necessary except for when the controller itself needs a different orientation then the bone object.

the need for no offset in constraints could be due to not knowing the results with the offset, i had them bugging out on me a couple of times

I found that further along there were expressions reading the rotation values, which the rigger wanted to start at zero, simplifying calculations.

Also having the child node of the control drive the rotation of the bone allowed for some scripted deformation (on the child node) while leaving the control object free for the animator.

I think that your inverse setup might allow the same.

Some animators are fanatical about zeros, because they like to grab a bunch of stuff, put zero in the channel box, and get back to default pose. Others prefer to have meaningful numbers (if your zero pose is the same as your bind pose, “0,0,0” on the shoulders could be a 45,15,0 angle visually.

You should drive the design of the rig off the in-house preference. I’m not sure there’s a bigger truth behind the choice than animator preference – I do know it’s something they are often very attached to.

The more I think aboutit the more I compelling I find the second reason (more flexible options for scripted systems)

For example consider a set of bones and controllers for deforming the lips:
you want them to be driven by the jawbone motion, and perhaps phoneme or emotion scripts, but also be available to the animator for custom tweaking.
So you’d need to script a node that can drive the bone and still allow for animator control in a second node.

And the more I think about it the more peerKe88’s scheme seems more useful
scriptedNode_parent.controlObject_child -> OrientConstrain -> bone_object