Agreed. I think in the case of RPMs and Debs, it evolved to this point. I would guess the first versions of RPM and the macros were amazingly easy to package, probably much better than PKGBUILD is now.
The problem happened that software started getting written in tons of different languages rather than usually in C, with different libraries/dependencies, different strategies and edge cases, and the system kept expanding to accomodate. Eventually it's a mess because there are too many macros, it's now too magical, and documentation hasn't been made a high priority because it's a relatively small group that uses it, and they don't need the docs. Once you know it too, there's not a lot of reason to change it and even more reason not to change it (cause that's a ton of work for little to no gain among the majority of the maintainers). I don't mean this as a criticism, just a pattern I've seen over and over having worked on software for a long time.
I think the actual package format for RPM probably doesn't need to change too much, it's the tooling and docs that do. I'd love to see a new project that is compatible with the RPM format but uses a system more like PKGBUILD.