Camera side, display side
The signal path has two conversions. Light hits a sensor and is encoded (OETF). Code values reach a panel and are turned back into light (EOTF). The deliberate mismatch between them is the OOTF, the opto-optical transfer function, and it exists because a picture viewed in a dim room needs slightly more contrast than a physically accurate reproduction would give.
Which is which in practice
PQ is specified as an EOTF. SMPTE ST 2084 defines how a display should turn code values into absolute luminance, and encoding is done with its inverse. This is why PQ content behaves predictably across displays: the standard fixes the display end.
HLG is specified as an OETF, in ARIB STD-B67. Its display behaviour is relative to the panel's own peak, which is what makes the same HLG file look different, and correct, on a 500-nit and a 1,500-nit screen.
The asymmetry is worth internalising because it explains the formats' characters. PQ pins the output; HLG pins the input.
SDR's version
BT.709 specifies an OETF close to a 0.45 power curve, and displays apply an EOTF nearer 2.4. The gap is that same OOTF, applied by convention rather than by a written specification, which is one reason SDR grading has always been somewhat display-dependent.
Questions people ask
Which one do I actually need to care about?
The one your file declares, which is what color_transfer reports. smpte2084 means PQ and arib-std-b67 means HLG. Whether the standard defines it as an EOTF or an OETF is a specification detail; the field is the practical answer.