I'm sympathetic with your general idea that much that is now done inside widget libraries should be pulled out into independent systems. It will need some thought on my end.
As to formlib, I'm afraid I don't really know much. I've seen Zope Schemas, and I think they are fine, though as I remember they did validation without conversion, and I think two-way conversion is integral.
Zope 3's design considers two-way conversion the responsibility of the widget, as it's part of viewing logic. Conversion might be quite different if the data is coming from another source than the web, or is going to another target than the web, after all (an int might already be an int).
Combining validation with widgets and worse data bindings is a really bad path, and you didn't go down that. I'm a little wary of data bindings in general, as it puts the logic in the framework and I hate that; it makes my head hurt. But if it's done really well it's possible -- as long as you aren't squeezing it into a normal web app framework design. I suppose htmlfill is a kind of data binding library; but it's very clearly a library. Anyway, no one will accuse Zope 3 of being a normal web app framework design, so no problem there ;)
Zope 3's more normal than it looks like, it's just not presenting itself well. :)
As to data binding, what you mean by this is the code that gets the data to display in the form from somewhere and then gets it back from the web into the application, right? I believe in Zope 3 that's scattered a bit between formlib and the widget system. It'd be nice if it were a more coherent library. It's quite powerful in the sense that it handles nested and/or composite form values well (which can be expressed with Zope 3 schema).