I'm rendering in ACEScg and have a problem when applying point colors to my mesh.

As an example, take the color 0.5, 0.6, 0.7 (RGB 127, 153, 178).
If I type these values into a Color SOP to assign the color to my mesh and append a PointVOP that contains an OCIO Transform node (Utility - sRGB - Texture -> ACES - ACEScg), the resulting Cd attribute reads:
0.26, 0.31, 0.43

However, if I don't use the PointVOP and instead use the Color SOP's color picker to pick the color from a Photoshop window, the resulting Cd attribute reads:
0.10, 0.13, 0.23

Why is there a difference? I can't figure out how to get the result from workflow two, which appears to be correct.

Looks like a bug, a conflict between Houdini's color picker applying gamma correction and the ocio ‘color_picking’ space transform also being applied. If you click the little ‘gamma’ icon in the color picker dialog to disable Houdini's gamma curve, and then click it again to enable color picking correction, the color picker should pick the same color as would be generated by:

I still get a small amount of error, even with this fix, but no where near before.

This seems to work. Now I'm just confused as to whether this is the correct workflow for getting the color into ACEScg?

I previously used Utility - sRGB - Texture into ACES - ACEScg
If I use Role - Color Picking into Role Scene Linear I get vastly different results.

Turns out that these roles are just aliases.
Color Picking is the same as “Output - Rec.709”
Scene Linear is the same as “ACES - ACEScg”

So I guess the last bit I don't understand is why Color Picking should be handled differently than an sRGB texture, i.e. using Output - Rec.709 instead of Utility - sRGB - Texture

They are for difference purposes, for color picking you generally care about the appearance as displayed–the operation is reversible to get back the color that was picked from the framebuffer.

The texture operation is specifically for converting sRGB format albedo maps (regular images) into acescg linear format. It doesn't reverse the tonemapping inherit to the aces display output as it is not intended for reversing images previously output for display, which might produce overbright values. It's a very simple transform: reverse srgb ‘gamma’ curve, then apply rec709 to acescg color matrix. If it makes more sense for your workflow to use the Utility srgb texture profile for colorpicking, then the ocio profile can be modified. Note that this will not produce a reversible transform, and colors picked this way will not match the source when output for display.

I understand, thank you for explaining!