It's due to math basically. Rounding errors and the fact the sources of the information are slightly different.
Basically the p75 overall number is what is correct, and what should be used. It is both an input and an output of the CrUX data set for the dimensions queried (e.g. device and url/origin in PSI).
The histograms are made up of post-filtered data and certain data below thresholds is filtered out. For example, if you have a very low amount of 2G data that might be filtered out and we'd only show 3G and 4G data in CrUX and in CrUX-calculated data like the histograms.
So it's possible on occasion to get a p75 TTFB of say 799ms (which is good), but for the histograms to say only 24% of navigation were good. This makes no sense as you'd expect at least 25% of values to be good to have a good p75 value. But it's due to the fact that the histograms don't have the full data.
In most cases (like in this example) the discrepancies are small and they usually happen on when a metric is at a border of a threshold, but it was enough to be disconcerting to users and have them questioning the accuracy or the data in PSI so we added a note to explain that we're aware this happens, and which number is the more accurate number (the p75 metric value).