I’m not sure about that, since it depends on the error margin tolerance one has.
Regardless, my biggest gripe with most reports of quantitative information I stumble across is that, lacking mention of significant digits accuracy, it’s very easy (and I’ve seen this happen a lot) for people to attribute more accuracy than what is there to a value.
One example: AWS cloudwatch reports external replication delay in MySQL Aurora in milliseconds, which is impossible, since the value reported by MySQL is in seconds. Yet many times I’ve been involved in discussions with people who say “our system can tolerate at most 500ms” of replication delay for reads, because they see the value reported in that unit.
There is no rule of thumb, except that people should understand that I can give the illusion of precision to every measurement by capturing crap. Those 32 bits on your laptops onboard audio interface are the real banger, when even the least significant digits in 16 bit mode are filled with electromagnetic interference and noise from the power rails. Real, actual precision is way more hard to reach and you will know when you reach it, because you will have spent a lot of money on the way.
Whether you need it, or wield it correctly is a different story.
In my experience reporting models in industry, even 1 or 2 decimal places are irrelevant to the overall decision to be made, at least if the number is around "87%" as stated in the example.
Of course it's context dependent. If you're evaluating incremental improvements perhaps that warrants more careful precision.
After all, by definition each decimal place is 10x less important.