If you estimated the lowest on multiple things - you got the one where you deviated the most.
If you overestimate everything - and you never finish things close to the mean estimate - that's a sign you're a low performer...
This is but a different kind of a rat-race?
Is that something that should've been caught in integration tests? Why did it pass review then?
As long as it's not a pattern, it's not a problem.
If something super severe happens - that's an organization-wide problem...
It's very hard to find axiomatic statements like those, that actually work in the possible multitude of contexts.
Which assumptions are behind that statement?
Does the team have uniform experience working in a single product? That statement feels more applicable here.
Or are there multiple work streams that aren't even touched by a few members and everyone is involved in estimations for everything? That statement feels less applicable here, and trying to enforce it could lead to experts in one workstream to be considered low performers, which motivates a consulting style lowest bidder environment, probably ending in overworked people and low quality code reaching prod.
This makes it easy to uncover simpler solutions (if everyone had a higher estimate) or pitfalls (if everyone had a lower estimate).