Believe it or not, a lot of it is due to a shared global namespace with global variables as the norm.
It's hard to capture the qualities you mention without that. (Raise your hand if you can think of a system that did; I'd love to know.)
There's more to it than that, of course – the design is excellent – but convention matters, and elisp has a convention not seen in most other large-scale programming systems.
Definitely this. It just feels so natural to have all those functions in the same scope without dealing with modules, hierarchies or something involving both.
I also believe that none of the languages with module hierarchies are suitable for some kind of REPL driven development. You can't just dump all of your program into the REPL and expect it to work. You need globally unique names for these. And I believe this is a must for a language that is running inside an editor.
Common Lisp has packages and is certainly as suited for REPL-driven work as Emacs Lisp.
I'm not convinced that a lack of at least a flat set of namespaces (like CL) wouldn't be an improvement on Emacs' "prefix everything" approach. Perhaps more important to Emacs Lisp is that everything is open. If you took just something like CL's packages but had every symbol exported by default you'd get something that's not a far cry from Emacs' present approach but with better code organization capabilities.
But of course Common Lisp has similar qualities: one can still write unexported symbols, there is just the worry that the internals may change. I think the important qualities are that the configuration is typically done with global and buffer-local variables (a super-lightweight and extensible solution to the obvious problem of per-buffer state) with simple types (alists, hooks, etc).
One issue with Common Lisp style packages is that they may interfere with lazy loading. In emacs you can setq a symbol before the package loads and then the defvar will not change the value, but in CL you cannot read the symbol until the package is defined so things like eval-after-load (ie lazy load then configure) suck.
It's hard to capture the qualities you mention without that. (Raise your hand if you can think of a system that did; I'd love to know.)
There's more to it than that, of course – the design is excellent – but convention matters, and elisp has a convention not seen in most other large-scale programming systems.