This is correct but misleading. The me_cleaner approach, with all options, wipes the entirety of the ME firmware except the module needed for hardware bringup. It then causes the ME to crash as soon as hardware bringup has happened. The host system cannot communicate with the ME processor and the ME processor does not execute any further code after this point. This is the current gold standard.
The next stage would be to disassemble the bringup modules and figure out what exactly they do by reverse engineering, and implement that part independently. People are working on this. So far there is no indication that any of the problematic functionality is in the bringup module.
Nothing requires that the ME initializes the hardware - the BIOS can do so as well. So if the initialization sequence is well-understood the ME can be disabled entirely and the initialization done by coreboot or whatever. This is possible on Intel CPUs. Unfortunately on AMD it doesn't work as unless the secure coprocessor clears the reset lines the other cores cannot wake up.
It seems likely, to me anyway, that the CPU doesn't have any effective way of verifing what is running on the ME. So reversed firmware could just lie to the CPU and tell it that its firmware is signed when it isn't. A similar approch is use the microg project to replace proprietary google play services by spoofing google's signature.
The next stage would be to disassemble the bringup modules and figure out what exactly they do by reverse engineering, and implement that part independently. People are working on this. So far there is no indication that any of the problematic functionality is in the bringup module.