1. Verify that debug features that are remotely exploitable are actually disabled in consumer releases of their hardware.
2. Re-implement proprietary parts of the boot sequence, such as activating memory controllers, in an open and public manner that can be more easily looked over for flaws, security and otherwise.
3. Modify parameters and tweak hardware for additional stability or performance enhancements, especially undocumented or disabled(on lower graded chips of the same architecture) aspects of the hardware that may be present.
On the other hand barriers include legal issues depending on what country people working on these originate from, ethical issues, and even industry barring, and this is not exhaustive. Consumers, especially consumers in countries not concerned about the legal aspects will likely gain the most advantages, if any are present.
Realistically, Intel will patch the firmware and replace the backdoors with new ones.
Unlikely.
Most projects won't come anywhere near this sort of thing. There may be a possibility of doing clean room implementation, but writing the spec based on stolen IP is the problematic step.
Then again, there is a high chance that none of this will be useful.
If you review the content and publish say a blog post, even without legal repercussions it can impact your ability to be hired in the future since everything you do from that point can be tainted.
So if you do look you should keep it quite or publish it under a pen name that you can’t ever take credit for.
Someone reads the code, mentions it to a friend, who adds it to a blog post, which gets cited in a wiki, which gets read by a developer unaware of the source. If the information is useful, it will end up getting spread.
Also, I would assume other processor companies hire people from other processor companies and everyone all wants the best, most of the basic knowledge would have already made it's way to AMD and other companies.
If you work in a completely unrelated field then you don’t need to care as much.