You don't want to use floating point numbers to represent monetary amounts, however financial applications often work with numbers that are not money. Consider risk modelling.
Do you think this really belongs on a blockchain, as a transactional environment? There's a notion that things like greeks and other non-linear inputs are best fed as inputs/oracles, for a number of reasons: 1) avoiding stochastic stuff on-chain 2) assurance, so you know what your inputs were later 3) impracticality of all that computation on-chain 4) dependence on market data. Of course there are simple things like imputing an option price from the stock with just delta and gamma, but a fixed-point decimal here wouldn't really hurt you; basic calculations like payment schedules would seem to benefit from fixed-point. But mainly, blockchains would seem to represent transactions and workflows primarily; analytics seem ill-suited for the high-assurance, database-write-heavy environment.
My knowledge of Solidity comes from reading the docs. It doesn't seem to support fixed point arithmetic either. The phrase "fixed point" appears in the ABI spec but nowhere else, shrug. Maybe half implemented? I guess you can implement it yourself as it does support bit shifts, assuming they aren't buggy too.
I pass no judgement on what belongs on Ethereum. I know from their website that they advertise it as a platform for general app programming and even implementing entire autonomous businesses. It clearly cannot support these things.
The Ethereum VM is not for general app programming. It's really not your typical environment. EVM contracts get executed on every network node, and it must return the same results everywhere.
We solved that for floats like 10 years ago. Let alone the fact there are better formats, like posits, or fixed point numbers, that also solve this problem very easily.