It may make sense but the it's non-trivial amount of work. I converted almost all the drivers we have in ardupilot to a new API which resembles the architecture of DriverFramework with small differences - the beginning of this works dates ba. I made sure they continue to work on all platforms we support, too. At least from my side there isn't any plan to do yet another conversion. Of course, if some one step up to implement and contribute the code, the change is welcome.
As you may have noticed in Linux, which is the platform supported by me and colleagues, we are going to use the IIO drivers inside the kernel - this was one of the topics of my presentation at ELC and Dronecode Unconference. Then we will have support for the current drivers in userspace (which may be easier for people not so familiar with Linux development to work) and the kernel drivers. From this point of view there's little gain to invest time on having the drivers shared since drivers inside the DriversFramework will suffer the same problems in Linux that we already have in our current implementation. Again, if people want to contribute drivers using DriverFramework in ardupilot, it's an welcome change... but it needs to work on all platforms we currently support.
Does it make sense architecturally?
As per above, it works, but it's not the optimal architecture.