First off, you're not exactly comparing like with like. You're trying to create an equivalence between kernel development processes and vendor kernel package maintenance processes. It's pretty clear these two processes are not entirely the same, because they've been significantly different in the past at RedHat and - despite any move to git at RedHat - they likely still are not the same. The preferences of developers in one mode may differ from those working in the other. The GPL does not specify exactly what "preferred form" is, no doubt quite deliberately, as it may vary from situation to situation.
The developers of one project can quite legitimately prefer to work on tarballs without history, while those of another may prefer to have the history. The *same* developers may follow two different processes, even working on nominally the same codebase, according to whether they're developing features for upstream or whether they're working on maintaining their employers supported package. That's certainly been my experience at another vendor, and you may have had the same experience too at your employer.
To be clear, there is a difference between "the sources for the Linux kernel" and "the sources for a vendor kernel package". It's an undeniable fact that, say, a RedHat kernel RPM was built using files that are not and (almost certainly) never will have equivalents in the stock Linux sources.
Further, I'm not sure there is much direct historical precedent. In the past, distributors built their packages from pristine+packages because SCMs weren't good enough. So, for package sources, for want of an SCM that could keep changes distinguished, the preferred form became pristine sources + patches. That this way of collating sources for packages became established at multiple distributors - including non-Linux ones - strongly suggests it was industry wide best-practice. I'd be amazed at anyone who tried to argue that wasn't the case. For me, such wide practise is somewhat equivalent to a preference, though you'd presumably disagree. However, in recent times SCMs have become much better. Git and mercurial (git especially) have changed how we can work and made it viable to move information that was previously kept in explicitly separate files in the sources of the package off into the history data of the SCM.
I have a lot of sympathy for RedHat. They've done and continue to do great things for free software. I do think it's legitimate to ask though, when a vendor deliberately tries to withhold information that was previously part of the sources they released for a package, at what point they cross a line. Maybe RedHat have not, but the discussion is still worthwhile.