I think the main problem is that you'd only use something like this (more accurately you'd only invest the time to learn how to use it) if you were doing something quite complicated - as he mentions, nested structs and whatnot. And since few if any people seem to need that much complexity with what they're doing, they don't see a need for it. It came up at about the time I started trying to work with DMA, but it was more than I needed so I never used it.
Which is a filthy, crying shame considering how fantastic it is and how much time went into it. As for speed comparisons, I'd say it's a fairly moot point since the library exists to enable things you can't do in vc rather than speed up things you can do. At least that's how I'm seeing it.

Feyr still consistently has me in open mouth awe at what he can achieve with humble vc.

I'm confused about why that is necessary.

Ahh. Well, you COULD do what Feyr presumably does internally and manage it all through DMA. Grue did that for some V2 thing he never released.

If you need nested structs or _anything_ OOP, this library looks just fine and capable to me. The source for what Feyr does is incredibly sensible and understandable. I'm not a DMA wizard, but it makes perfect sense to me, and I doubt you'd have any drawbacks to it -- I mean, it's just DMA, and not even a lot of DMA for data access (unless of course, you could do multiple levels of nested structs).

I'm not sure offhand if Feyr made a DMA string implementation or not.

Aen once made a dma-string library for v2, but it has not been ported for v3 dma as of yet.