FrameTimingMetric has a few issues that make it hard to align with user impact, from internal feedback/discussions:

frameDurationCpuMs accounts for the UI slice, but surprisingly doesn't account for any main thread delays from runnables that delay Choreographer#doFrame from starting. (This was an old decision to keep behavior consistent both pre 31 and post 31, when expected/actual frames were available, should consider revisiting.)
frameOverrunMs does account for delays, but still treats runnables different from in-frame work, due to how out-of-frame runnable main thread delays will delay the expected frame in the frame timeline.
Jank rate is a helpful single number when evaluating specifically how bad is the current device experience. Yes, it has the drawback of not tracking improvements/regressions that don't affect near-deadline frames, but it's still worth offering. (especially as gfxInfo-based metric)
lack of frame count makes it difficult to compare different frame metric sources, verify they're looking at same data (important when comparing gfxinfo vs perfetto frame metrics, or when one scenario produces needless extra frames)