My first response is this is why I prefer looking at saturation (pressure) metrics first, since time spent waiting covers all scenarios (hardware- and software-limited). Why you start looking at the S from the USE method.
But for reporting utilization of a half-throttled CPU: I'd report it as 50%, and, include another metric for the current software limits. In a world of containers, monitoring software needs both hardware and software-capped utilization reported.
True, as with turbo boost, it's makes things painful. If you report the baseline (unscaled) then perf is sometimes weirdly faster. If you report the max possible (highest step) then 100% across all cores is usually unobtainable. /
We've been down this hole recently, and from an app PoV, I do think "effective utilization" matters.
With rlimits, if I'm exhausting my allocated cycles, that's 100%. (Apps may make decisions based on approaching this number)
To your point, I'd report saturated util. separately.