or any other value where you have repeated calculations that would introduce errors
Storing monetary values as FP is one thing, but I've seen phone numbers and other numeric identifiers (long time ago before PCI-DSS even credit card numbers) stored as FP values, with predictable results.
You may say it's easier to know how they are stored, then you can derive the implications anytime you need them. Maybe that works for you, but most people who I know that got this wrong do actually know how FP values are stored, they are just drawing the wrong conclusions. So better focus on the implications, cause it's those that matter.
I already expressed this in the GP comment, and it's a little shocking to see all the replies that didn't actually pick up on that.
I don't think that's true at all. You're merely looking at a symptom of someone who is intrinsically a negative performer. But that's rather like assuming that someone with a cough has tuberculosis.
It also depends on your philosophy. I want to master my machine not be its servant.
Don't get me wrong, once you go down to embedded you sometimes do need to know and sometimes it just improves your understanding (and it's kinda cool anyway), but if you do high-level work, perhaps web work, all you need to know is the abstract interface of floats as a data type. What operations you can do, what is guaranteed about the result of those operations (loss of precision etc). In other words, why would a Haskell programmer need to know the IEEE FP standard?