This is why I always just use an int64 on embedded systems for timestamps. I'll be dead of old age before my software kills anyone by accident.
log2(10^22) = 73.08
log2(10^25) = 83.05
However there are languages that are looking at F128 (https://rust-lang.github.io/rfcs/3453-f16-and-f128.html). The problem is that there isn't really hardware support for them yet so you'd do it through software.
As someone who does it, financial math is often done at a precision of more than 1 cent. This is the reason that most (high-latency) financial libraries use strings underneath.
This al doesn't address the high order floating point arithmetic of geo-spacial, which was the Patriot issue.
I personally find FP math perfectly find when you are dealing with numbers "small enough" to fit the datatype you're working with. The issues with overflow exist in both integer and fp's alike.
Your original claim was that Int64 would not work for financial calculations. For most normal calculations it would be fine, and for tax purposes it would be too, as the tax authority defines exactly when to round and how (at least in Denmark). If you retain the fractional precision the "true" calculations have, your tax calculation would be wrong.
No matter what you use, it is always a tradeoff between precision, range, and speed. Floating point have been use a lot because they provide relative precision and have much bigger range and vastly faster speed compared to the same range in integers. But that comes with a lot of gotchas. To get the same range as a 64bit float, you need around 1024bit integer, which will inevitably be slower and require more memory.