Frame rate is the unit everyone uses and it is the wrong one, because equal steps in frames per second are not equal steps in anything you can perceive.
Thirty to sixty is a jump of thirty. A hundred and twenty to a hundred and fifty is also a jump of thirty. The first is the difference between a game feeling sluggish and feeling responsive. The second is close to imperceptible. Nothing in the numbers tells you that.
Invert it
Frame time is the milliseconds between one frame and the next, which is simply
frame time = 1000 ÷ frames per second
In that unit the comparison becomes obvious. Thirty fps is 33.3 ms a frame and sixty is 16.7, a saving of 16.7 ms. A hundred and twenty is 8.3 ms and a hundred and fifty is 6.7, a saving of 1.7 ms. The first change is ten times larger than the second despite looking identical in frame rate terms.
This is why the returns feel like they stop. They do not stop, they just shrink hyperbolically, and frame rate hides that by reporting the reciprocal of the thing you care about. The FPS to frame time calculator does the conversion and shows the saving collapsing as the numbers climb.
The ratio that matters
Your monitor can only display a new image when it refreshes, so the frames actually reaching your eyes is the lower of your frame rate and your refresh rate. Everything above that is rendered and discarded.
At 144 fps on a 60 Hz panel, 84 frames every second are thrown away. Your graphics card is doing nearly two and a half times the work that reaches you. That is not entirely wasted, because uncapped rendering can reduce input latency slightly, but it is close.
The ideal ratio is roughly one to one, with a small margin. If you have adaptive sync, capping a few frames below your refresh rate keeps you inside the variable range and avoids the latency penalty of hitting the ceiling. If you do not, matching them avoids tearing and heat for no loss.
Averages hide the problem
A 90 fps average sounds comfortable. A run of 11 ms frames with an occasional 50 ms frame averages to roughly the same thing and feels terrible, because stutter is variance rather than mean.
This is why 1 per cent low figures exist and why they are worth more attention than the average. Put your 1 per cent low through the conversion as well: if the average is 6.9 ms and the 1 per cent low is 25 ms, you have a stutter problem that no amount of raising the average will fix.
Adding up the chain
The real reason to work in milliseconds is that everything else in the latency chain is already measured that way. Input polling, render queue, display response and network latency are all in milliseconds, and frame time is one term among them.
Converted, you can add them. Left as a frame rate, you cannot, and you end up guessing at which part of the chain is costing you. For the other half of aim consistency, see the piece on sensitivity.