I'll be surprised if this goes anywhere other than to replace RH's aging, crufty initfs system--so, they need to do the work anyway. I'm glad that they are working on something else--it's a total pain to modify it now.
But, here's why I don't think anyone else will adopt it: I worked for a company a few years ago that built a custom thin-client software stack. I wrote all of the initramfs integration. At the time the project started, I looked around for a nice framework that already existed that I could just reuse so that I didn't have to reinvent the wheel. I evaluated every distro's initramfs generation framework. In short, they all have terrible kludges and assumptions about the host OS and requirements EXCEPT for Debian's initramfs-tools. The design is simple, elegant and completely agnostic. And it works in just about every boot case you can possibly imagine with a fully pluggable boot method system (which we abused liberally).
I think it will take a few years for Dracut or any other solution to reach that level of maturity. And I just don't see any Debian-based system switching to Dracut until its forced on them--because what they have now is so, so nice.
It's a shame that this is yet another Redhat NIH. (And I don't buy the explanation that it was done to encourage adoption. If it's the right technical solution, people will use it.)