Tooling and ease of use.
The way the web was done at the time was in a text editor. That is, JavaScript was not feed into a tool that would spit some binary format, because that is not how you develop for the web. Instead, if you develop for the web, you pick a text editor, any text editor, and you type. No special tool required. Well, we have minifier and other stuff now, but, back then? No.
Because of this, any binary format was not going to be popular※.
We can kick the question up to why is HTML not compiled? Well, because it was never meant to be a programming languages (and, despite being a declarative way to tell the computer what to do, the consensus is that it isn't), it is for documents instead. Why compile that? You don't need a compiler, you need a document viewer. Part of the popularity of HTML on its beginning was that it was simple to implement a viewer, and viewers were made for different platforms. A binary format would have been an obstacle.
HTML, was, of course, based on SGML, which also was text based. Why was SGML text based? It was meant to remain readable, independently of the technology, long term. Thus, it could not depend on a particular machine code or binary format that would require an specialized interpreter that might become unavailable as technology changes.
※: Except Flash, right?
If you wanted to play simple animations on the web, Flash would give you an smaller file size (and thus faster to load) and higher quality than the alternatives. Because it was vectorial. In addition to that, Flash popularity also derives from the fact that the player was free, and the tools to produce it were easy to use. Then eventually ActionScript was added to it.
Yet, despite entire sites made in Flash, it could never replace HTML and Javascript. Not only in that producing HTML was cheaper (no need to license specialized tools), but also simpler. If you wanted to generate dynamic text (HTML and Javascript) on the server it was trivial to do, while generating dynamic Flash on a server was virtually unheard of. Thus, for any enterprise web application that wanted to hit a database or a mail server, Flash was just not an option. This kept Flash confined to client-side interactive content.
Please notice that if Flash didn't have animation, just ActionScript and access to the DOM (it could not access the DOM, at least not directly, but imagine it could), then it would not have been popular. And that is what a binary format JavaScript would have been back then.
Ironically, this also meant that you would not use JavaScript for complex client-side interactions. Thus JavaScript code was relatively small, and thus the cost-benefit of a binary format was not in its favor.
I also want to mention that an interpreted language, as JavaScript used to be, has some benefits. For once, it is easier to implement a security model.
Plus, it would be easier to make it tolerant to mistakes… Alright, that needs some context…
Let us say, I am an sloppy JavaScript programmer, who would not be bothered to validate/check my code. And my site works on Browser A, but not Browser B, because Browser B is more strict with JavaScript code. What is the client perception? That Browser A is better! For market share there was, and still is, an incentive to make the browser tolerant to bad HTML and bad JavaScript. Up to the point that this tolerance has been codified and standardized, and what was sloppy back then is correct now.
This is also why competing browsers approached some level of parity on non-standard behaviors and features. Emphasis on "some".
On the other hand, if the browser was strict, as in the failed XHTML, any small programming mistake (say, a missing ;) would mean a failure to render the page or run its code.
Well, it is easier to implement a tolerant interpreter than a tolerant ahead of time compiler. Well, it is easier to implement a interpreter than any other kind of compiler, period. However, the incentive to make it tolerant would translate into an incentive to not go into the effort of using something else than an interpreter.
Which finally brings up to why we ended up compiling JavaScript (as in, not just running it in an interpreter) anyway?
Speed, of course.
In the decade of 2000, interest in large client-side web applications (as opposed to, you know, desktop apps, which require installation) was growing. And as large JavaScript applications (notably google's) began to appear, the performance issues of JavaScript engines also began to appear.
Around this time Ajax was coined, Apple decided to not put Flash on the iPhone, and a lot of standardization effort of web technologies began around this time.
So Google decided to make a better and faster JavaScript engine. Which, by the way, some people argued it was not possible, because JavaScript was a dynamically typed language with some unique challenges. V8 showed it was possible. It would also eventually power Node.js and bring JavaScript to the servers.
It is this same desire for large client-side web applications that would spark NaCl, asm.js and eventually WebAssembly.
