You do not need to go to raw JS/CSS to get good performance out of jQuery Mobile. But you won't get it "out of the box", either.
A good strategy is to consider JQM widgets as prototyping tools. As you develop experience with your app or site, replace the most speed-critical parts with your own custom HTML/CSS. In particular, heavily-used lists, for example.
You also need to deal with flaky transitions and the iOS click delay.
The best transition, really, is no transition. The "none" transition is fast. If you can deliver pages fast enough, then the "none" transition will generally provide a better user experience than any other. In a native app, there usually is no problem delivering pages quickly. I use the Rhodes platform, which is programmed mainly in Ruby - a notoriously slow language - and a sqLite database using a property-bag scheme. None is this presents as big a performance problem as do transitions and listviews. Take out the transitions and listviews, and you can write native-performing apps in Rhodes.
I think that users generally prefer no transition, but if you can't deliver the page quickly enough, they get impatient. A transitions gives them something (generally, useless, though) to look at while they wait. And the thing is, they actually have to wait LONGER. But the transition fools the user into ignoring the delay before the transition starts, as long as it isn't too long. With a "none" transition, it is obvious if you are slow delivering a page.
So, if you are using JQM for a website, you need to work on improving latency - carefully select your server location(s) or use a CDN. Try to minimize round-trips. If you are developing a native app, I think generally it is not a problem, though.
So, what is left to use JQM for?
Forms generally aren't large. Constructing a form generally is not a big performance hit. Content pages generally aren't a big problem. Listviews and transitions are huge bottlenecks.
Part of the listview problem is unreasonable expectations by developers. If you are trying to scroll lists of hundreds of items, you are asking for trouble. It's a bit hard to accept, since iOS (and, presumably Android) has a very efficient native implementation for lists, that can very seamlessly scroll lists of any length, getting data directly from a database. Given the roundabout way that you have to scroll the same list using HTML/CSS/Javascript/JQM, it's amazing it works at all. You have to get it all into the browser or go to extrodinary trouble to manage unseen list items. Contrast this with the elegant native methods that simply make a callback to your code to get the next or previous item.
Keep your lists short.