In my opinion, the behavior you've noticed indicates that CinGG is sending only sRGB signals to the monitor. It's not a matter of whether or not color management is enabled. I have wide-gamut ICC profiles set system-wide, so CinGG (or any other program) should display a wide-gamut signal if it passed the signal through unaltered, but CinGG limits it to sRGB. I’m attaching an image taken from the website https://www.wide-gamut.com/test, similar to the ChromaChecker you posted. The top color strip is wide-gamut (ProPhotoRGB); the bottom strip is sRGB. On the linked webpage, since I have a wide-gamut monitor, I can clearly see the difference between the two images: the top one is much more saturated and vibrant.

In the CinGG Compositor, I don't see any difference.
This fact does not limit color accuracy only when the source files are sRGB. Any other color space is reduced to sRGB, so we end up performing color correction based on an inaccurate monitor display; consequently, the corrections made would lead to an even greater discrepancy (metamerism). With BT.709, the difference may be acceptable since the gamut is the same and only the brightness (gamma) changes. With wide-gamut color spaces, the difference becomes unacceptable.
What I still need to figure out is: why does changing the “YUV color space” affect the view in the Compositor? If we only ever see sRGB on the monitor, it should always look the same, and this setting would be useless (unlike “YUV color range,” which I understand does make a difference).
Now I’ll try compiling with lcms2, using P3 and OCIO images, and the new parameters for zscale, to see if anything changes. I’ll let you know tomorrow.