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.
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.
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.