Exactly. Floating point is inappropriate for anything related to accounting (payments, balances, etc.), but when the numbers you're producing are effectively forecasts or estimates, it's no different than what floats were originally invented for (numerical modelling in physics and engineering).

I remember someone demanding that we needed to run our Monte Carlo pricer on 1024 paths, that 256 just wasn’t precise enough and one of the risk guys said “Well since we know our assumptions are wrong I’m not sure what difference it makes.”

The difference between precision and accuracy in a nutshell.

Can cause issues if you are accounting for things, e.g.

"The sum of these values need to equal the sum of these values"

In that case you'd then needs to avoid

"sum_a == sum_b"

and use instead

"abs(sum_a - sum_b) < SOME_SMALL_VALUE"

You don’t do that though, there’s no use case to account with the output of a model.

I'm not sure what you mean - aside from speculative pricing models there are regulatory constraints too, that are a part of the same codebase.

Not to mention that there is a use case for auditing pricing models (as in external requirement, or internally) or comparing alternative models.

Sure we add up the numbers, but there are thresholds for everything anyway. We might not be concerned about something within a 1MM range let alone a floating point inaccuracy. The uncertainty is accounted for already.