I think generally relational databases are going to be faster than triple stores for the tasks in which they overlap. But that's not entirely surprising, relational databases have a decades long head start in terms of research & development.
So if you have a task that is easily represented in a relational model and an RDF model, it's probably going to be faster using a relational database.
But that's not to say that triple stores are not fast or scalable, that's a fallacy. They're optimized for the requirements of storing RDF and answering SPARQL queries. I'm not an academic, but it does feel like the research in these areas has increased quite a bit over the last ten years.
I'd say all have optimized indexes, how those optimizations work and are applied will probably different from store to store as the access patterns differ for each query engine, but they're quite optimizied. You can't really tinker with them in the same way you can with relational stores, but in my experience, that's for the best. The database vender knows how they should behave better than users.
Most have query planners or at least some form of query optimization built into the query engine.
Lastly, there are significantly more triple stores than Jena & Sesame, which primarily are APIs into triple stores, though they provide notably TDB & Sesame Native as their home grown triple store implementations. Stardog, OWLIM, Virtuoso, 4Store, Mulgara, Parliament, BigData are some other offerings that come to mind.
The short of it is, if RDF is appropriate for your application, then use it, and use a triple store. If a relational model makes more sense, then go with a standard relational database. If you try and shoehorn one onto the other, you're gonna have a bad time.