A. How do you contribute to the kernel in a way that only benefits the contributing organization? That's quite literally impossible in this kind of project. Even the more niche stuff like virtualization support is used by homelab enthusiasts. It's also not like Linux has 100,000 APIs for every customer under the sun.
B. Most of the effort goes into hardware enablement; CPUs, GPUs, power management, etc. Without corporate interests, try running Linux 2.2 from 1999 on a modern PC (which came out just before the $1B IBM investment). See how well it works. Fork modern 2025 Linux, and try running it on a computer that comes out in 2028. See if it even boots. If Intel's only done a minor refresh, it might work; if it's something bigger like the split to P cores and E cores, expect a brick. Even if it does boot, don't be surprised if it crashes, acts unstable, has borked performance, broken sleep/wake, broken audio, broken USB, you name it, it's probably broken.
C. A forked Linux would not have the same level of security research behind it. For example, the Linux 4 era was marked by the introduction of fuzzers and the fixing of countless bugs. A C codebase with handwritten Assembly is rather unlikely to ever become bug-free. How well would your forked non-corporate codebase handle Spectre and Meltdown, just an example, with Google's experts contributing the technique for fixing these problems efficiently (Retpoline)?
D. Added to the above, this isn't a hypothetical: The FSF didn't like the practice of proprietary firmware blobs being in the kernel; so they made their own commercial-interest-free version of Linux called Trisquel. It still uses commercially written code if it's open source; so even it can't be called completely free of commercial influence. The kicker: It runs on almost nothing, and people were complaining about how it works on nothing 13 years ago.
TL;DR: A forked Linux, is a broken Linux, that will never run well on newer hardware, and will quickly become insecure.