This is not the cost of mainlining, but :
overlap with existing driver.
inclusion of features that do not belong in the hardware.
For instance, I doubt you could convince a V4L2 maintainer that a driver doing BGGR to UYVY (ie format conversion) inside the driver is appropriate, and they would be right, this is not a good technical solution, the right thing to do is do the postprocessing in userspace.
However we have a customer with a lot of existing code using UYVY format, and for some reason, they don't think they can introduce soft debayering in these existing tools. So we provide a hack that as legitimately no place in mainline
Even without this unusual use case, not an option does not mean "won't be accepeted in mainline" but not interesting because :
-not flexible enough
-time to market (and time to bugfix / new feature)
-uncertain cost / benefice ratio.
In fact, distro balkanization is a problem that can be easily avoided by distributing the source instead of the binary. UEFI is potentially a huge hurdle to module source distribution. However according to M Garett :
"We're planning on using Suse's approach of permitting local key management at the shim level, and I spent some time discussing this with Vojtech last week. In combination with the above, this should provide a workable mechanism for permitting the end-user to install module signing keys. "
So it seems out of tree module will remain a possibility.