From previous reading of Linus rants, it sounds like they're pretty particular about keeping source code and git history clean. Why didn't they go back and reverse the new root created by the README.md repo?
His rants are also pretty particular about not rewriting published history. As he said on the linked message, "[...] I didn't notice the history screw-up until too late, [...]", so he probably already had pushed to the public "master" branch on the git.kernel.org servers. Once it's there, other kernel developers might already have pulled from it, so trying to rewrite the git history to remove the commit would only lead to an unholy mess (and the offending commit coming back) the next time he merges from them.
I have spent the last 2-3 years educating auditors and after quite some effort, they have learned to appreciate git. To the point where they are now starting to ask some of their other clients why _they_ are not doing something similar.
Auditors LOVE immutability. To be fair, git doesn't provide that, but it provides the next-best alternative: tamper detection. If anyone rewrites history, git will show that. The gitrefs between two points in time will not match if anyone has modified data or commits in the meantime. The auditors also have no problem looking at previous years' documents where they have recorded the relevant gitrefs at the time.
This has gone so far that this year's policy review was a breeze. Our compliance documentation is maintained in a git repo, with all documents as markdown files. The final documents are simply compiled PDF and HTML artifacts.
In 2016, the auditors asked if we can provide snapshots of previous policy versions. In 2017, they already understood that we have everything in git, and knew to ask for clarifications as to when a particular change was done and who had signed it off. This year our auditors literally asked for the latest compliance documentation bundle from CI, all the individual commits, and the overall diff over the year.
As long as the audits are for purposes where there is actual competition[0], this is possible.
The important thing is to never treat compliance audits as box-ticking exercises. That's a never-ending, vicious cycle. In fact, many of the findings are simply different aspects of the same thing. You can pre-emptively work on this: identify what parts of requirements are essentially duplicates, and make improvements that satisfy all of them at once.
Then proudly flaunt them. When you can show to the auditors, in person, that you have considered the wider business implications and worked to understand the compliance requirements, you are on much better ground. That buys trust.
Then, educate the auditors when necessary. Show them in practice how something simple can provide a better trail and an improved experience. When possible, provide evidence in the format they initially ask for, but also in the format which is more suitable and more convenient. Auditors are humans. They just often are not aware of the leading edge, of what is possible. Show off solutions that are more convenient to both of you.
They will learn. They will be impressed by some things you do. Anything that makes their job easier, while satisfying the intent and spirit of the audit, will be an easy sell. They also believe in repeat business. Show repeatedly that you know what you are doing, and why you believe that your approach makes more sense (while delivering better audit trails).
Convenience is a strong currency.
0: There are some domains where a single company has essentially a "Royal Charter". These are much, much harder to deal with, because the monopolist has little need to employ personnel with proper technological understanding. They can also strong-arm and bully their customers at will, because there are no alternatives. Audits like these can very easily degrade into box-ticking bonanzas. My advice for these cases is: pick your fights. Double down on what you truly believe and give in on smaller, less disruptive items. Rinse and repeat on subsequent years.
Honestly his attitude in general seems to be "once live, it stays", no matter if it is git commits, "broken" APIs, or anything really (just check out his recent opinion on the C standard).
Likely because that would mean rewriting public history, which I believe Linus is opposed to, particularly in the case of a huge project like the kernel.