Sencha touch is a little more complicated for those used to web design to use, in that it is almost a purely programmatic model (you don't design pages in html, you programmatically add elements to a page). It does, however, have a much richer widget model and is a lot more fleshed out than jQTouch (it is also a lot bigger)...
JQTouch is much easier to get running on the fly (you basically design pages in div's on a single page), however, if you plan to have a lot screens you have to be very judicious about either breaking the app into multiple pages or creating your pages dynamically in Javascript as (at least on a lot of versions Android and on the iPhone 3G) DOM manipulation with a lot of pages tends to be where slowness happens.
Although Sencha touch appears to have a lot more documentation (at least it is certainly more organized and in a central place), I've actually found it harder to get a simple 3 or 4 page app running. The doc for jQtouch is kind of all over the web, and you need to spend some time finding the resources (Jonathon Stark's two books (iphone , android), the peepcode screencast. Now that the webpage reflects the code's movement to Github rather than google code, the actual git repository is easier to find (a fork of the google code used to be the first few hits on google). And now that Jonathon Stark has taken over stewardship of the project which David Keneda had kind of let lapse while he was working on Sencha touch, things seem to be getting more organized.
I don't know if this helps, but my suggestion is to try to write a 2 or 3 page site in each and see what you and your developers find easiest. For now, I am sticking with jQTouch, but that could change as Sencha (or another technology) improves. The important things is to keep most of Javascript code your write as library agnostic as possible...
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
