Besides obvious documentation, tools and dev.support costs, also compatibility cost. Currently Intel/AMD can change the microarchitecture however they see fit, potentially even between revisions, as long as the instruction set stay stable.
Changing the microarchitecture itself is not trivial either, and you can bet that they've got it all documented internally along with tools and whatever else. They could just open it up, as in post everything on their website for download --- they don't have to provide "support". The only real reason they don't is because there are things in there that they don't want the world to know.
Major changing is not trivial. However I can see how they can implement minor tweaks between revisions that don’t affect their main interface (i.e. AMD64 instruction set + extensions) but do affect microcode.
> you can bet that they've got it all documented internally
I’ve worked in a couple of large US software companies. I won’t point fingers but the internal documentation I’ve worked with wasn’t OK. The only exceptions is when the company provided a public API. When that was the case, they allocated resources (developer’s time, plus sometimes a technical writer position) and did the job.
> along with tools and whatever else
Legal issues are likely. E.g. GPL-licensed code is fine in an internal tool, but if you want to distribute it, you have to also distribute the source code of everything else that’s linked. Sometimes you don’t want to, other times you just can’t (if it links to a commercial library you’ve bought).
> because there are things in there that they don't want the world to know
I don’t eliminate the possibility but I don’t think that’s likely. As you see, there’re pragmatic reasons (i.e. money) why they aren’t doing that.
The good thing is, if anyone (Intel, AMD, I dunno, Apple, Qualcomm) will do that, and it will indeed deliver a great value to the users (such as free ASAN), the rest of them will do the same really fast, because competition.