There is a pervasive and generally useful notion that is popular among application programmers that if you run a complicated floating-point calculation and are unsure if the answer is correct, a simple check may be available: If a higher precision version of the program can be run, try it. If you get the same answer in single as well as double, then it is probably correct. Or double and quad, etc. While this can be merely signal agreement to the wrong answer, why are we not happy with it?
(Followed to its logical conclusion as has been done by some hardware designers, one finds many niceties eliminated. Who cares if the results are entirely accurate; if it matters, the computation will be re-done to higher precision and in wider exponent range arithmetic.
Sloppy division, rounding incorrectly, cavalier treatment of underflow, imprecise interrupts can all be excused in the name of speed.)
Why should we care? It depends on who is meant by ``we''.
An engineer needing a one-off solution of a problem that is in the middle of a very well-conditioned problem might not care, except that he might be wrong and his problem is on some border (or his program is unstable).
We as suppliers of supposed quality hardware and software should care [ref:WK's Matlab's Loss is Nobody's Gain]
When one is constructing software for re-use by others (libraries, interactive engineering packages etc), then one cannot put a cost on inaccuracy.
In particular, the numerical software ``engineer'' cannot generally judge for users of some library
Purveyors of software and hardware must protect the (relatively speaking) naive users from excessively inaccurate computation.
``Kahan's Law on Precision''
An increase of K significant bits in an intermediate result's accuracy decreases by 2^(-K) the incidence of numerical embarrassment attributable to the later use of that result.