I switched to Emacs a year and a half ago when I started using Clojure, and customized it heavily for the first few months. But I avoid customizing it any more. I'm never truly satisfied with what I end up with, and I hit too many frustrating walls trying to make it just right.
One major problem for me is the plugin ecosystem. There's Melpa which is easy to use and has the most up-to-date packages, but they're built off of HEAD which makes them extremely brittle. Many plugin authors decry Melpa and say that if you installed their package from it, then you're on your own. There's also Marmalade but I haven't found it to have nearly the same scope of packages.
For the first couple of months I was customizing the hell out of Emacs. Then the things started falling apart and I've switched to the 20-line long .emacs and empty .emacs.d (well, almost empty if you don't count key-chord/ace-jump-mode combo which makes file navigation a mindreading experience)
Are you sure that MELPA has issues? I've been running with it since it started and one thing that I can say about it is that its been a joy to use. Hats off to milkypostman & sanityinc for maintaining it.
If you do have an issue, I suggest you open it on MELPA's GitHub issue page and I'm pretty confident that you'll get a quick response.
As for tweaking Emacs' config, yea, I have to admit, I've spent time on it too and things can always improve.
The issue Melpa has is that it builds from HEAD, whereas many package authors treat HEAD as a working state that should not be used directly. Melpa doesn't (or didn't last time I checked) have support for building off tags or non-master branches, which would solve this. And if I remember correctly, when I raised this issue, he disagreed on some philosophical grounds. So it's an inherent problem in Melpa.
On IRC we get a steady stream of confused users (in both the #emacs and #clojure channels) who added melpa because some library recommended it in their readme and they didn't realize it would cause every package they use to also pull from the unstable branch. It is a huge support headache.
However, these days I only very rarely find packages that aren't available on Marmalade. When I do, it's usually enough to ask the maintainer nicely and they start publishing to Marmalade; it's not a difficult process by any means.
But one of the issues with Marmalade is that anybody can fork your project (patch it or not) and just push it. With MELPA, they try to get the original authors to submit the projects. If you've got patches, they are pretty strict about it and encourage you to get them merged in the package rather than accepting a fork.
Hmm. Is there a particular repeated source of breakage? I only use MELPA, and apart from the recent nrepl->cider migration (which was intentionally piloted on MELPA) I've not had any instances where my work was hindered by package issues. And as a maintainer, I update my packages daily.
Or a feature. ;-) Don't forget that el-get has been popular for years, and it pulls dev versions of libraries. I don't see any compelling evidence that breakage is more frequent for MELPA users than for those who only use Marmalade.
It's correct that we don't want our current packages to build off non-master tags or branches, and that's because we've a bigger picture in mind. It's a concrete goal of MELPA is to provide two parallel archives of packages: the existing one, filled with "bleeding edge" packages, and a new archive containing "stable" packages which have been built from the same upstream sources, but using existing version tags found there. We're making progress with this goal: see https://github.com/milkypostman/melpa/pull/1407, for example.
If we can pull this off, this will yield the best of both worlds: users will get known-good versions of packages, and at the same time they will be confident that the stable packages came from the upstream developer's source tree (which isn't at all assured with Marmalade). It will also make releasing a new stable package as easy as tagging a source repository.
Recent versions of `package.el` allow packages to be pinned to specific package archives, which lets those concerned about bleeding-edge breakage pick and choose between "stable" and "unstable" packages on a case-by-case basis.
Actually, I'm also on the "less configuration, less trouble" side. That's why I like some minor mode to let me get rid of what I don't want to see, sometimes.
Agree with the less is more idea when it comes to configuration. An additional benefit to this is that it's more comfortable to use vanilla emacs when you need to work on hosts you don't typically use.
One major problem for me is the plugin ecosystem. There's Melpa which is easy to use and has the most up-to-date packages, but they're built off of HEAD which makes them extremely brittle. Many plugin authors decry Melpa and say that if you installed their package from it, then you're on your own. There's also Marmalade but I haven't found it to have nearly the same scope of packages.