IMO it's too soon to write this off. As far as I know Luc is presenting this as being "a better approach all things considered" (ie it has more benefits than drawbacks), not a quick fix to an urgent problem the developers face every day.
If I were a developer up to my a$$ in KMS/GEM/TTM/DRI2 alligators I wouldn't be spending time looking at this right now either, but I sure would come back and look hard at it in a month or two when the spring distro releases had settled down.
I wasn't able to get to FOSDEM so I can't comment on how the initial presentation went but from everything else I have seen this seems to have some good ideas that may get picked up over time.
The big question, which I don't know if anyone has answered, is whether the interfaces between core code and HW drivers changes more than the interface between HW driver components. Certainly the last year has seen a lot of changes between the components in a given HW driver stack, which argues strongly for the modularization model Luc is describing - the question is whether that is likely to still be the case after the architectural transitions of the last couple of years settle down, or whether the code base is more likely to see more "change a piece of Mesa and 6 HW drivers at the same time but don't touch ddx or libdrm" architectural work, which would suggest that something closer to the current model might be more appropriate.
Either way, it seems to me that we need to find ways to make the open source driver stack more accessible to new developers, and while I know that the current "hands-on" developers understand it very well I do have to say as a relative newcomer that "it sure isn't intuitive for the new folks" and it does seem like at least some of Luc's proposal could help to lower the entry threshold and help to increase the size of the developer community.
My 2 cents, anyways.