This problem gets worse with localized formats. In my locale, $13.377 is 13377 dollars and zero cents. And $13,377 is 13 dollars and 37(and something) cents. Obviously, CSV exports randomly chose my locale, their locale or something else. Same for date-formats. But at least date-format errors are visible and often obvious. Having a giant table of prices and a very few being off by a thousand, isn't.
Add, indeed, the localized formulas and you end up with sheets that are completely unportable, unsharable.
I'm certain that this is because Excel was designed in a pre-internet era. Where collaboration, if it existed at all, evolved around intranets, shared drives and company-managed computers.
This is an issue with CSV numerical values stored as strings, for numbers it's a bit better. Libraries sometimes allow for a raw import that preserves the internal data type of the format, then you get proper numbers, not adjusted to locale formats.
If you do it for excel it even handles dates pretty well because they're in a numerical format and you can infer that a column is filled with dates because of the range.
The pre-internet conclusion is right. They try to keep backwards compatibility. Also, Excel doesn't handle big data well (1-2M rows) and neither do import libraries (at least in JS land).
Add, indeed, the localized formulas and you end up with sheets that are completely unportable, unsharable.
I'm certain that this is because Excel was designed in a pre-internet era. Where collaboration, if it existed at all, evolved around intranets, shared drives and company-managed computers.