I understand perfectly well the IT requirements. However, capabilities which originate for quite benign reasons but which allow complete, persistent, and undetectable system compromise are typically called "bugs".
For example, I don't have any issue with remote power control. A secure form of Wake-on-LAN is wonderful, as long as the public keys are fully enumerable and totally under operator control, and the feature can be decisively disabled if desired.
To your point about packet processing, to keep with the Wake-on-LAN example, it's perfectly easy to share a physical port and keep the traffic fully visible to the OS as well as a separate processor.
If a remote party has permission to completely own my system, I want to see their name (public key) listed every time the machine boots, like the warning you get any time you access a government system;
You are accessing a [Company Name] information system, which includes (1) this
computer, (2) this computer network, (3) all computers connected to this network, and
(4) all devices and storage media attached to this network or to a computer on this
network. This information system is provided for [Company]-authorized use only.
Unauthorized or improper use or access of this system may result in disciplinary
action, as well as civil and criminal penalties.
By using this information system, you understand and consent to the following:
You have no reasonable expectation of privacy when you use this information system;
this includes any communications or data transiting or stored on this information
system. At any time, and for any lawful government purpose, the government may,
without notice, monitor, intercept, search and seize any communication or data
transiting or stored on this information system.
The government may disclose or use any communications or data transiting or stored on
this information system for any lawful government purpose, including but not limited
to law enforcement purposes.
Such a warning, requiring an 'I Agree' click at each boot, would adequately explain the risks to end-users of having such a component active on their system. But apparently, the more common practice is to
hide the prompt at startup (typically Ctrl-P) to enter the MEBx Configuration screens behind another BIOS setting.
I'm not an expert at vPro or Intel AMT by any stretch, but upon cursory investigation, it appears the trust model (a.k.a all you need to completely own a system) is an easily obtainable certificate, and control over the DNS and DHCP server. It looks like the only thing that protects a system beyond this is a vendor-specific "remote configuration timeout" which would have to be reset by a local agent after it has expired. [2, 3] However, some Intel documentation claims that TLS-PKI "...allows a client system to be provisioned with zero physical interaction. Remote configuration is ideal for systems that have already been deployed into an environment..." which implies some way to overcome the remote configuration timeout... (See 'Alternate Path #2' on footnote #5)
[1] - https://software.intel.com/en-us/blogs/2009/10/07/intel-amt-...
[2] - http://h10032.www1.hp.com/ctg/Manual/c03455054.pdf
[3] - https://communities.intel.com/docs/DOC-1989#SECFAQ8
[4] - http://downloadmirror.intel.com/21729/eng/RemoteConfiguratio...
[5] - https://software.intel.com/en-us/articles/intel-amt-use-case...