RPM having all the packaging written on a single file, mixing both shell scripting, changelog, dependency, you name it... is simply a horrible idea.
Why?
Having actually packaged other people's software with and without patches, the specfile method keeps meta information, the phases of pre-installation, setup, post-installation and your dependency information synchronized nicely. Of course, if you really need separate files you can just use the %include macro on recent rpmbuild versions. Put meta info in a header file, changelog in changelog.txt, dependency in another file, you name it.
You could argue that building an RPM is actually a little, too easy. Low barrier to entry means you get plenty of crappy RPMs (looking at yours, Skype) and flavor of the day naming. This is also a problem for Ubuntu PPAs. If the specfile looks horrible because the packager cannot script well, that has nothing do to with rpm's quality.
It could be worse. Like .deb's numerous mandatory directories. All the extra control files needed even if you don't use deb feature XYZ. And control files that are white space sensitive. Not good Python-style sensitive but I'll-kill-your-cat and get-off-my-lawn-80-column-punchcard Pascal sensitive.
But having built both types of package I can say that I prefer the apt-tools and front-ends which yum (and things like software.opensuse.org) is certainly catching up too. On the other side rpmbuild is quite nice, being pretty much make for packages. I've gotten better packages out of running alien on rpms than what the deb tools do with some native control file configurations.
IMNSHO, the debian package format is over-engineered (or poorly engineered...white space, bleh.) But the debian developers are in their right to be very anal about how packages are built, even if the specifics of it are masochistic to the poor distro folk having to make the package. The higher barriers means that packagers just cannot fart out a crappy package. They have to build something that is intended to be used within a greater system, apt. That apt ecosystem can then be built on that more stable ground.
But I'm betting like with apt vs yum, it's the superior end user interface which will win out here. The devs, packagers, icon makers and what not will continue to toil on the backside with the tools at hand, scratching those itches or raking in that corporate pay. And maybe someone's manager (or UI 'designer') will figure out that desktop and mobile devices just might need different UIs.
Although in the end, after enough customization does your original distribution even matter?