Presumably because it allows you to do anything involving double precision or 32-bit integer arithmetic, and performance was not originally a major consideration. It's pretty rare to need more than 53 bits of precision (and was even rarer for JS's original intent), so it makes sense that the numeric type is kept simple. Edit: and to clarify, the advantage is that this makes basic implementation extremely simple. Only if you want to optimize your engine's performance do you have to worry about shuffling types around.
These days the solution for having more precision is to use an external library. I think that's generally fine, although I think performance is a concern. Financial applications aside, working with arbitrary precision is a good hint that you might be doing something processor intensive. It's certainly a case where I'd like the library to be compiled to target asm.js, and maybe optionally NaCL, once those have widespread adoption. Ideally, ECMAScript would also have a native implementation, but that won't eliminate the need for a library for shimming for years to come.
Performance was always enough of a consideration that even BE's original implementation had both int32 and double types internally, though black-box unobservable (as in the black box, everything appears as a double).
As a side note, I'll bet you could have actually observed the difference via timing at the time, assuming you knew what hardware you were working on. On an early Pentium, a floating point add would have taken up to 3 times as long as an integer add (depending on implementation), so by comparing in a loop, you might be able to tell if a given value was being treated as an integer or a double.
These days the solution for having more precision is to use an external library. I think that's generally fine, although I think performance is a concern. Financial applications aside, working with arbitrary precision is a good hint that you might be doing something processor intensive. It's certainly a case where I'd like the library to be compiled to target asm.js, and maybe optionally NaCL, once those have widespread adoption. Ideally, ECMAScript would also have a native implementation, but that won't eliminate the need for a library for shimming for years to come.