Hell, even Scheme would be a lot nicer than Emacs Lisp. Actually, if I could even get Yi ( http://www.haskell.org/haskellwiki/Yi ) to work, I'd use that. Elisp sucks.
Mostly stuff for my own personal use inside Emacs; i.e., nothing important. I'm sure that disqualifies me from ever speaking of it again, but there are objective reasons I dislike it (the dead horse of "lack of lexical scoping" comes to mind).
Lexical scoping is mostly for defensive reasons; its absence shouldn't prevent you from writing code. It only prevents a very narrow category of bugs -- a type of bug that is especially uncommon in elisp, because most variables are bound with let, rather than set with ... uh ... set. That means, even if you accidentally use a variable name that the caller has, you still don't clobber the caller.
Some parts of Emacs are made quite convenient with dynamic scoping, in fact. It's nice to be able to say "(let ((inhibit-read-only t))" and run a bunch of editing commands that ignore the fact that the buffer is read-only. If you had to take the Java-style approach of passing the "inhibit-read-only" flag to every buffer modification function, writing an editing function would be quite tedious. And, you'd have to remember to include the "inhibit-read-only" option on any composite functions you would write, otherwise you'd be deleting features from Emacs (for future users), just because you're lazy. Not good.
In general, programmers are taught that everyone using and maintaining their code is dumber than them, and to make sure that nothing unanticipated is ever possible. Programming for Emacs is the opposite, though -- you have to keep all possibilities open, because the next programmer is smarter than you, and understands the ramifications of what he wants to do. (Because if something fucks up, it only takes a few keystrokes to fix it. The user of your programming tool is very different than the user of your web app. He's a programmer in an environment that's meant to be programmed -- breakage can be corrected immediately.)
Anyway, people like to repeat "guh, global variables suck" over and over again, but the reality is that lexical scoping is not that important of a feature. When it's added (which it already is), it's not going to suddenly be easier to write extensions. You will just have one less possibility to think about when debugging, and many opportunities to accidentally make Emacs harder to program, by removing opportunities for future programmers to tweak the behavior of your code.
Dynamic scope is fantastic and I dislike using any language that doesn't have it. That said, I find it annoying in emacs to write code that uses menus because what I would like to do is build the menu and attatch a closure to the different "buttons". Since I couldn't find a way to get callable closures using the cl package I ended up writing some kind of global button-position table. Yuck.
As to your point about "global variables suck", people say a lot of misinformed things. The problem with global variables has always been the inability to detect their access. If a variable has a value you didn't expect, it's not lexical so you can't just read the code and it's not dynamic so you can't just check the stack for the culprit.
Ironically, the main thing our OO saviour has really brought us is the ability to limit the scope of our global (member) variables. With big classes you still have the issue of figuring out what in-scope method changed the member variable, and I've sorely missed dynamic scoping for member varialbes many time (e.g. anytime you use a finally block to make sure the variable gets set back, you could have just used dynamic scoping).