I know it's a big no-no, but I find it odd that we can live with limited precision in scientific computations (even have to), but can't when it comes to money.
The whole "NEVER use floats for money" thing is cargo culting. In this situation though I don't see why floats would be any better a solution than just using 64-bit integers.
I'm sure one can think of plenty of counter examples, but I'll give an example where floating point numbers are used heavily and you don't typically don't care about minor rounding issues.
Computational chemistry can be used to predict the geometry of molecules. The model used to make this prediction has to describe the interactions between the atoms, which is computationally expensive (solving Schrodinger's equation). So often times the molecule is only modeled in a vacuum and not as a liquid (where there would be many other molecules included). All of these add up that even if there was no IEEE-754 floating point error, the answer would still maybe only be right to +/- 10%.
So science is quite different from finance, where the main goal is to converse a certain quantity. Money shouldn't be created or lost though rounding errors.
Sure, it's humorous and a little bit silly, but the issue is a real one, and this is a funny way to familiarize yourself with the tricks that can be played.
HFT + floating point = economy crashed by duping inflation without real item duping
The key is whether your system needs to tally up your monies into a known quantity and ensure it is all accounted for. If you summed up the transactions across a number of customer accounts at a bank for instance, it's critical that they all net out.
Two orders of magnitude isn't really very much headroom.
So if this next-closest share price got closer to the limit, it would almost certainly split long before it became within one order of magnitude of the limit.
BH is just a different duck that way.