TimeQuest is not quite PrimeTime, but a very impressive STA tool especially as part of a low-cost suite. Coming from a Design Compiler / PrimeTime background, I managed to find many of the kinks and shortcomings in early versions of TimeQuest, and Altera worked through them quickly and diligently.
I could probably still find a few SDC constraints it doesn't support (or support exactly like PT), but it's been good enough for a HardCopyII tapeout.
As far as accuracy goes, when Quartus/TimeQuest generates a netlist for PrimeTime, it also generates the SDF timing data, which is coincidentally the exact same numbers TQ computed. PT reads the SDF and obviously reports the same numbers as TQ, so PT adds no value there. If you don't use the SDF, then PT's calculations are garbage, because PT is optimized to do deep submicron timing calculations based on SPF/SPEF and other detailed physical information that it just doesn't get from Altera's libraries or placement files.
However, if you're fluent in Tcl scripting and familiar with PrimeTime, PT offers a lot more powerful netlist navigation commands for finding and reporting on certain nodes, collections of nodes, and so on. Since those are really API commands instead of SDC constraints, Altera does not have to support them to be SDC compliant. As a result, some of my fancy PrimeTime scripts won't run in TimeQuest.
I also found that some of the naming conventions were not the same in the TQ netlist/database and PT netlist/database, and areas like clock pins on a source-synchronous DDR output were not handled correctly a few revisions ago (I haven't revisited them lately).
Another oddity is that TQ makes some kind of modifications to the database when operating on it (and I really disapprove of that). I typically open 4 STA windows (HardCopy fast, HardCopy slow, Stratix fast, Stratix slow) and analyze them all as one big interactive session. PrimeTime has no problem with this, but since the Quartus max and min data for a Stratix run winds up in the same directory, you can't (couldn't a few revs ago) analyze max and min simultaneously in TimeQuest. However, I could compare Stratix fast and HardCopy fast side-by-side (ditto for slow corner), but never all 4 at the same time in TQ.
As far as performance goes, TQ (standalone) is fast. As the integrated timing engine used during quartus_fit, it seems to run faster and produce faster designs (on my limited testcases).
As far as whether PT catches more violation than TQ, I don't really think that's quite the issue. Both only report timing on paths that are constrained (be default), so if you've missed some constraints, neither tool can report a timing violation. In both tools you can check for unconstrained paths, and both tools do a good job of catching them. For unconstrained paths, you can set a variable that allows PT to report them with the report_timing -from -through -to commands. I think TQ requires a report_path command or something slightly different in that case (another minor annoyance).
Summary: PT = no major advantage for FPGAs, except in netlist navigation and scripting (and vendor independence) TQ = very good imho, but not in the same ballpark as PT. (The $50K+ price difference and maturity of the tool might have something to do with that! ;)