Although I've contributed a few (very minor) patches to the Linux kernel, I don't count myself as a kernel developer. However, here's what I know:
A driver written for kernel version 2.6.0.0 pre-dates the elimination of the Big Kernel Lock (BKL) that happened in kernel version 2.6.39.
The BKL was created back when Linux was still a single-processor (single-core, single-thread) OS. As soon as SMP support was added, the developers recognized that the BKL was going to become a big bottleneck at some point, but as long as there was just a few cores/threads in the system in total, it was somewhat tolerable. But it first became a real problem for people using Linux in supercomputers, and so the work began to replace everything that needed the BKL with more fine-grained locking mechanisms, or whenever possible, with lockless methods.
On modern computers, which may have double-digit numbers of cores on regular desktops and high-power laptops, let alone servers, a 2.6.0 backward-compatible kernel module API would also need to implement BKL.
If a legacy module says "I want to take the BKL", the rest of the kernel has no clue what the module is planning to do with it, and so the backward-compatibility mechanism would have to take all the locks that replaced the BKL just to cover all the possibilities. That would be a big performance hit. And the new lockless methods would also need to check for the legacy lock - which defeats the point of being lockless in the first place. So the very existence of the backwards compatibility mechanism would degrade system performance, even if no legacy modules were actually loaded.
More recently, the Spectre/Meltdown security patches made big changes in what needs to happen when the kernel/userspace boundary is being crossed. Any modules compiled before the Spectre/Meltdown fixes were implemented can be unreliable with post-Specre/Meltdown kernels.
Just two weeks ago I was troubleshooting an old server that needed manual power-cycling when security updates were applied by automation. This had happened several times before, and was reproducible. I found out that it had a very old version of the proprietary megasr
storage driver from before the Spectre/Meltdown patches, which was not included in the automatic updates. After updating the driver to the current version, the problem went away. By the way, this was on a plain RHEL 6.10 system.
I've also seen servers crashing when loading proprietary pre-Spectre/Meltdown hardware monitoring drivers with a post-Spectre/Meltdown kernel. Based on this experience, I'm fully convinced that the Spectre/Meltdown fixes need to be treated as a watershed event: the kernel and the modules need to be either all before-fixes, or all after-fixes versions; mixing and matching will only lead to grief and midnight wake-up calls for the on-call sysadmin.
And since Spectre was a CPU design level issue, it is "a gift that keeps on giving": some people will find novel ways to exploit the weaknesses, and then the kernel developers will need to figure out ways to block the exploits.
These are just two of the big problems a 2.6.0.0-compatible legacy kernel module API would need to solve. I'm sure there are many others.
And then there is the more philosophical side. Think about it: what makes Linux possible?
A big part of it is open hardware specifications. If the hardware specifications are open, anyone can participate. As the source code of the operating system is open, anyone can contribute, for the benefit of everyone. And you cannot keep hardware programming specifications as your trade secret if your driver code is open-sourced.
Linux kernel developers tend to believe in the open source model. That is why they have made their design and development choices so that the preferred way for the hardware manufacturer to participate is to open-source the driver, get it merged into the main kernel source distribution, and then (and only then) you'll get to benefit of the entire kernel developer community in maintaining it.
This provides some incentive to hardware designers and manufacturers to make this possible. If you have something you wish to keep secret, make the effort encapsulate it into an ASIC, or perhaps into signed firmware if you must. (If you do the latter, please grant others the permission to redistribute the firmware package.)
But since the kernel is open source, the kernel developers cannot exactly prevent others from maintaining proprietary drivers separately. But they have no incentive to care about them either.
In fact, the extra hassle caused by proprietary binary drivers in kernel debugging is an incentive for kernel developer to not care about proprietary driver development: "They make my work more difficult, why I should do anything in particular to make theirs any easier?"
So, the kernel developers generally do what is the most advantageous for them as a group/community. If that includes some module API change, so be it. The third-party drivers don't even enter the equation.