The following information has been obtained (and is shared) as an interoperability effort.
It is based on a lot of attempts and analysis against OmenMon and OMEN Gaming Hub (OMENCommandCenter_1101.2412.5.0_x64) as of 2024/12/17 on a HP Victus 16s-1034nf laptop (Ryzen 5 8645HS and RTX 4060M, 8C9C board)

Note: every described queries are performed using HP WMI command 0x20008

Setting the ECO mode
 - Performs 0x1A query with 4 bytes {0xFF, 0x30, 0x00, 0x00} which means setPerformanceMode(Default = 0)
 - Performs 0x29 query with 4 bytes {0x37, 0x37, 0xFF, 0xFF} which means setPowerLimit(PL1=55W, PL2=55W)
 - Performs 0x22 query with 4 bytes {0x00, 0x00, 0x01, 0x57} which means setGpuTgpPpab(MaxTGP = false, PPAB = false, GpuDState = D1)
 - According to RyzenAdj, the 3 following values: STAPM LIMIT, PPT LIMIT FAST and PPT LIMIT SLOW are set to 65W, 65W, and 55W when running on AC (35, 35, 25 on battery)

Setting the Balanced mode
 - Performs 0x1A query with 4 bytes {0xFF, 0x30, 0x00, 0x00} which means setPerformanceMode(Default = 0)
 - Performs 0x29 query with 4 bytes {0x37, 0x37, 0xFF, 0xFF} which means setPowerLimit(PL1=55W, PL2=55W)
 - Performs 0x22 query with 4 bytes {0x00, 0x01, 0x01, 0x57} which means setGpuTgpPpab(MaxTGP = false, PPAB = true, GpuDState = D1)
 - According to RyzenAdj, the 3 following values: STAPM LIMIT, PPT LIMIT FAST and PPT LIMIT SLOW are set to 65W, 65W, and 55W when running on AC (35, 35, 25 on battery)

The only difference between ECO and Balanced mode seems to be the discrete RTX 4060M GPU chip drawing 67W as maximum on ECO versus 80W as maximum on balanced (nothing else seems to change).

Setting the Performance mode
 - Performs 0x1A query with 4 bytes {0xFF, 0x31, 0x00, 0x00} which means setPerformanceMode(Performance = 1)
 - Performs 0x29 query with 4 bytes {0x41, 0x41, 0xFF, 0xFF} which means setPowerLimit(PL1=65W, PL2=65W)
 - Performs 0x22 query with 4 bytes {0x01, 0x01, 0x01, 0x57} which means setGpuTgpPpab(MaxTGP = true, PPAB = true, GpuDState = D1)
 - Performs 0x29 query with 4 bytes {0xFF, 0xFF, 0xFF, 0x1E} which means setConcurrentTdp(30W) 
 - According to RyzenAdj, the 3 following values: STAPM LIMIT, PPT LIMIT FAST and PPT LIMIT SLOW are set to 65W, 65W, and 60W when running on AC (35, 35, 25 on battery)
 
In Peformance mode, the RTX 4060M GPU chip power draw is allowed to go above 80W (but not above 120W which is the maximum according to NVIDIA specifications).

Note about CPU power limits:
 - According to AMD Ryzen Master SDK, using AMDRyzenMasterCLI.exe --api GetPMTableData, PPT Fused Limit is 65W in my case (while cTDP specification from AMD for this CPU given to [35W to 54W] configurable TDP with 45W TDP as default).
So it seems that there is a factory allowed extra power margin from HP due to the heat sinks / fan / VRM designs.

Setting the fan speed to Max speed
 - Performs 0x27 query with 1 byte {0x01} which means setMaxFan(On)

Setting the fan speed back to Auto
 - Performs 0x27 query with 1 byte {0x00} which means setMaxFan(Off) - but it has no effect (fans are still running at maximum speed)
 - Performs 0x2E query with 2 bytes {0x00, 0x00} which means setFanSpeed(cpuFan = 0, gpuFan 0) (then fans are going back to dynamically applied fan speed).

Reading the actual/measured fan speed
 - Is done by performing 0x2D query with 1 byte {0x00}, which is answered by 128 bytes! First byte describes 1st fan speed (CPU in my case), second byte describes the 2nd fan speed (GPU in my case), and so on.
 - Obtained values should be multiplied by 100 to get RPM values.

Note about a "timeout" / "keep alive" mecanism:
Appart from reading fan speed, none of the above settings (power modes and fan speed) are being used if 120 seconds passed since the last "FanCount" query. I can confirm I observed OMEN Gaming Hub periodically doing it.
When timeout occurs, according to RyzenAdj, the 3 following values: STAPM LIMIT, PPT LIMIT FAST and PPT LIMIT SLOW are set to 45W, 45W, and 45W when running on AC (35, 35, 25 on battery).
 - To go (and keep) out of the default mode, you can periodically perform 0x10 query with 1 byte {0x00}, which is answered by 4 bytes. First byte contains 0x02 in my case (for 2 fans), and the others ones contains 0x00.

Note: current Performance mode cannot be retrieved using EC_read. This is what I noticed about EC registers on my laptop. But it turns out they differ a lot between HP laptops, so using them into a driver may be a really bad idea.
 EC Registers 0x8A and 0x8B are showing currently used cTDP values (I've seen 45/45, 65/60, 65/55 switching accordingly to current values)
 EC Register 0xAE is showing 0x02 during default mode, 0x01 when ECO/Balanced mode is active, 0x00 when Performance mode is active, or when on battery 
 EC Register 0x8F goes from 0x00 to 0x04 when going from ECO to Performance mode
 EC Register 0xB6 goes from 0x1D to 0x1E when going from ECO to Performance mode
 EC Register 0xB7 goes from 0x1D to 0x1C when going from ECO to Performance mode 
 EC Registers 0xB0, 0xB2 and 0xB4 seems to show CPU, IGP and GPU temperatures
 EC Registers 0x11 and 0x14 seems to sometimes show current fans speed but 0x14 is sometimes stuck to a wrong 0x3A value while fan is low, and in max fan speed, 0x11 seems to instantaneously show a theoric 0x3A value instead of a measured one.