Windows can be booted into test keys mode, which allows the loading of unsigned drivers. We don't consider that a security issue because the privileges you need in order to switch to that mode are equivalent to the privileges you get by switching to that mode. It's the same here - the ME is the root of trust on Intel platforms. If you're in a position to execute arbitrary code on the ME then you've already got the ability to compromise the rest of the system enough to run arbitrary code on the host CPU, and being able to modify microarchitectural state doesn't give you additional privileges.
I’m not saying that’s the case here, but that’s the general problem with the line of reasoning that “hey if you already have permission X then doing Y is the least of your concerns”.
The concept of defense in depth literally relies on each barrier being independent and robust. That’s why you see hardening of Linux’s hibernate even though the common refrain is “well if you have physical access the game is lost”. There are things that even root can’t do even though “hey if you have root the game is lost”. The point of the game is to never lose even in very adverse environments.
The assumption on Intel is that there are no barriers once you're in the ME. You can't defend against a hostile ME. The security model is already violated. Maybe there should be a barrier between the ME and the CPU, but as can be seen here Intel feel that the ME should be in a position to put the CPU in debug mode so shrug.
