The thing is, and this is from direct personal experience, companies maintaining out of tree drivers don't put their driver through the Linux code review process; as a result, they ignore standard Linux interfaces in favour of inventing their own.
Add to that the fact that they lose interest in maintaining their driver at all when they've moved onto the new shiny (in the case of one vendor I've dealt with, the driver stops being maintained as soon as they have a new chip out, even though they're still selling the old chip), and the fact that I don't have the time to do more than bugfix drivers that have already been ported to new APIs, and I find myself thinking that all the advantages you claim for out of tree drivers are disadvantages from my perspective.
I want one place to go to for drivers. Not twenty trees, but the one tree on kernel.org. I have found it easier to backport drivers from 2.6.30 to 2.6.23 than to integrate vendor drivers, so I would prefer in- aiming to move into the tree (before GregKH's staging area), and that was quite enough pain.
I'm also afraid that your admission that you're stuck on an old kernel due to an out-of-tree driver from your board vendor reminds me of a subset of nVidia graphics card owners, who complain bitterly (regardless of technical reasons) when X.org releases a new version of the X server that isn't backwards compatible with the ancient version of the nVidia drivers that supports their older hardware; I do feel that you should be exerting pressure on your vendor to make this happen, either by getting their drivers into the kernel, or getting them to step up and do the work of maintaining a stable in-kernel API. It's not going to come for free, so why shouldn't the people who want such an API do the work of maintaining it?
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds