We tried jQuery Mobile on an early hybrid project expecting it to handle a lot of the app-like interaction patterns, swipe navigation, touch-friendly widgets, page transitions, for us out of the box. It does, but at the cost of a fairly heavy framework imposing its own styling and page transition model on everything it touches, down to form elements getting reskinned in jQuery Mobile's own visual language whether we wanted that look or not.
The specific breaking point was a client who wanted their existing visual design carried into the app rather than adopting jQuery Mobile's default look. Overriding its built-in theming turned into more work than just handling the interactions ourselves would have been, we were fighting a framework's opinions about markup structure, it expects specific data-role attributes and a particular div nesting pattern to recognize a page or a listview, rather than benefiting from them.
For our more recent PhoneGap work we've moved to handling touchstart, touchmove and touchend directly, more code to write ourselves but much finer control over exactly how a swipe gesture behaves, and no fighting against a framework's opinions about page structure. A basic swipe-to-dismiss gesture, for instance, is maybe thirty lines of plain JavaScript tracking the starting touch position and comparing it against the current position on touchmove, and we can tune exactly how far a swipe needs to travel before it counts, something that felt opaque and harder to adjust when it was buried inside jQuery Mobile's own gesture handling.
One gotcha we hit going this route: the roughly 300 millisecond delay browsers historically added between a tap and its click event, to distinguish a tap from the start of a double-tap gesture, made our custom buttons feel sluggish compared to native controls until we bound directly to touchend and handled the tap ourselves instead of waiting on a synthetic click event. That single change made the whole interface feel meaningfully snappier, more than anything else we tried, and it's now something we check for by default on any touch-heavy interface rather than only debugging it after a client complains the app feels laggy.
jQuery Mobile probably still makes sense for someone wanting a quick app-like prototype without much custom visual design, or a project where the default look is genuinely fine rather than something to fight against. For anything we're shipping to a client with their own brand and visual identity to preserve, we've found plain event handling worth the extra lines, even though it means reimplementing a few things, like graceful handling of scroll versus swipe detection, that we got for free before.