It's like this for anywhere where you don't need to compile anything. Perl is an example; Debian depends on Perl internally, so you really don't want to depend on it as a programmer because it's going to change according to Debian's needs. If you fuck up @INC by installing stuff in there, then you run the risk of breaking your operating system. So most Perl programmers on Debian use some combination of local::lib or perlbrew and just have a Perl-install-per-app.
Emacs is a little different in that nothing is going to break the system; but if user A wants Emacs extension A and user B wants Emacs extension B, but they conflict (say, by depending on different versions of foo.el), then the system can't resolve that. By delegating the management of third-party extensions to the user, this conflict is avoided.
My personal policy is that I only use OS packages for things I don't care about. I mostly use emacs, conkeror, rxvt-unicode and xmonad, so all those packages are intalled from git/darcs into my homedir so that I can easily hack on them. Stuff like "ls" I let the OS handle, because the stock "ls"'s featureset meets my needs.
Anyway, package systems are nice from an organization perspective, and there's no reason not to submit your favorite Emacs extensions to Debian. But it's not a perfect answer to every situation.
Emacs is a little different in that nothing is going to break the system; but if user A wants Emacs extension A and user B wants Emacs extension B, but they conflict (say, by depending on different versions of foo.el), then the system can't resolve that. By delegating the management of third-party extensions to the user, this conflict is avoided.
My personal policy is that I only use OS packages for things I don't care about. I mostly use emacs, conkeror, rxvt-unicode and xmonad, so all those packages are intalled from git/darcs into my homedir so that I can easily hack on them. Stuff like "ls" I let the OS handle, because the stock "ls"'s featureset meets my needs.
Anyway, package systems are nice from an organization perspective, and there's no reason not to submit your favorite Emacs extensions to Debian. But it's not a perfect answer to every situation.