The ACPI error turns out to be a red herring, since it is about the _SB.IETM._OSC method, which is something completely different from the _SB._OSC method that is used for negotiating USB4 support (see BIOS bug: `_TZ.ETMD` missing in ACPI tables - #2 by Matthijs_Kooijman for further discussion of that ACPI error).
However, looking at the decompiled ACPI table for the _SB._OSC method, it seems that that only (sometimes) clears bit 2 (PR3 support) and leaves all others as supported, so I think the first part of the native USB4 check should be satisfied.
However, the second part is where the kernel actually requests control over the USB tunneling using _SB._OSC with UUID 23A0D13A-26AB-486C-9C5F-0FFA525A575A (see linux/bus.c at b2d229d4ddb17db541098b83524d901257e93845 · torvalds/linux · GitHub) but it seems that the ACPI tables do not actually handle this method (so they return an unsupported UUID, which is probably silently discarded by the kernel).
So, I guess that means that the system / ACPI tables do not support using a software connection manager, so any fix must be in the “firmware” connection manager (though I’m not quite sure where this firmware actually runs - is there some kind of MCU that handles this, or is this firmware on the EC?).