The 50% is average overhead and basically entirely due to context switch overhead and execution serialization. If the execution is entirely in userspace, rr's overhead is basically 0. I don't think PT will help here. That said, rr's performance on Intel chips is entirely acceptable for single threaded code. The big asks would be other architectures, or as roc mentioned, something like QuickRec for efficient multi-threaded recording.

PT doesn't get you close to what rr can do, which is reconstruct any program state at any time in the recorded execution.

As Keno says in his blog post, the promise of rr is that if you have an rr recording, you are almost completely assured of having enough information to figure out the bug. That is what we see in practice, and it has big implications for developer workflow.