We certainly have (Parenscript) and it's vital for two reasons: (1) there are cases where we need to run the same code on either the server or the client; (2) we get the full power of Lisp macros. The latter means our source code is much smaller than JS we would have had to write by hand. Somewhat unexpectedly, there's a key efficiency issue here: making heavy use of abstractions in JS would make our code significantly slower. With Parenscript, we can write concise source code with nice abstractions that compiles to low-level, efficient (but still readable) JS. It's one of those rare times you get to have your cake and eat it too (an adage that really doesn't make sense, yet still always comes up #1 in the search results in my brain!)
Iteration/comprehensions work like they should, destructuring simplifies extraction, there's a prototype binding construct in the language, less line noise, and everything is an expression. I also happen to like indent-significant languages and think it's a great DSL language.
I could certainly produce the same code writing in JS, but what would the advantage be? I'm already doing a build step for combo/minification and if not, a --watch compile gives roughly the same workflow as raw JS. I have to search for a snippet of text rather than going to a line number when I'm debugging, but I think the coding gains/cleanliness is worth the slightly increased debugging effort.
 With one gripe, `y = x + 1 for x in 0...10` got changed in August to match up with `z = x if x % 2` and friends (it was special cased) so y is now 10 instead of the array 1..10 and you have to wrap the comprehension in parens.
If you can output JS that's fast enough, why not?
It comes with good UI building tools
This is just another example of how technologies are chosen by considerations other than objective technical merits.
Of course any language that does a lot more than CS is going to be slower, e.g. Objective-J's object system providing method-missing functionality and a whack of other features not found natively in JS.
Sometimes I think the holy grail for what we do would be a Slime-like REPL in the web browser that speaks Parenscript, maps to source code, and had full debugging support. In the meantime, though, things like Firebug are indispensable.
And a somewhat related list:
Hacking the PHP compiler and standard libraries in the name of turning it into a not crappy language.
Phuby wraps PHP in a loving embrace. Exposes a PHP runtime in ruby
implementation of the Java 1.4.2 library in PHP
Lisphp is a Lisp dialect written in PHP
Scala inspired syntax for PHP
a cross language compiler than transforms java code to php code deployable on any server supporting PHP >= 5.3
Pyhp is a way to execute PHP Source Code directly within Python Scripts
PHP parser written in Python using PLY
A PHP eval server for Erlang/OTP
The generated code from that won't run without a JS runtime implementation in CL backing the JS-specific Parenscript forms, which currently doesn't exist to my knowledge (it's not hard to write, just not very useful). This is useful by itself for writing JS analysis and transformation tools and moving JS code to Lisp.
This is a translator/compiler/"simulator" (http://www.cs.aau.dk/~normark/oo-scheme.html) that provides good integration between the two languages.
A full compiler would of course always have the problem of dynamically generated JS, i.e eval().