It's years later than people anticipated (and won't be in the E5 xeons for a couple more cycles, so 2017/2018/2019).
Not quite NetBurst level, but pretty horrible from a generally execution-excellent company.
Instead, I think that a bunch of MBAs showed up and decided SGX is security, security is an enterprise thing, so SGX must be pay-to-play. For whatever it's worth, I think the SGX designers did a pretty good job of separating the objectionable parts from the rest of the design.
For example, the EPID homebrew crypto is all in software, so Intel can change the algorithm without hardware mods or microcode updates.
Also, the way they set up the Launch Enclave gives Intel time until the very last minute to not be a douche. They still have the option to release a permissive Launch Enclave that only includes the checks needed to keep attestation secure.
The SGX design that doesn't come from MBAs is quite clean, given that it addresses the multi-layered crap pile that is X86. There are some cool tricks in there.
If the functionality works as is being described here, I feel they deceived the audience, both in their presentations and in 1:1 discussions.
This is especially unfortunate, since I know for a fact their actions have influenced purchasing decisions.
A Xeon implementation would have to secure the QPI links between the CPU chips. These run at significantly higher speeds than DRAM, so the current MEE design would likely not be able to keep up. Also, a Xeon implementation would have to somehow have the chips mutually authenticate each other.
That being said, I wouldn't be surprised if Intel was trying to see if they can get away with the licensing bs in desktops before committing resources to tackling the challenges that I mentioned above.
I expect AMD to clean up Intel's act on this.
The best "demo" of this in a fairly open way is USB Armory; they exposed the best features currently available in a developer friendly way. But there are some other things coming which are even better.
(I care about end users being able to trust remote servers; I don't really care about remote content owners being able to trust local client devices. There are usually no rights issues with the former, and DRM is the obvious (but not only) use case for the latter. I generally believe whoever buys a piece of hardware deserves full rights to it, but there are cases where that's an organization and they have ever right to expect all of their widely-deployed hardware is untampered...for instance, a closed computing environment for processing PII of third parties.)