I like the Arch/AUR approach too as you don't even have to host your own repo. With a good AUR helper that system is quite convenient for maintainers as well as users.
The problem with the AUR is its semi-official status takes the pressure off the 'community' binary repositories, while not being up to the same standards - many packages are out of date or don't build, and the complete lack of gatekeeping renders the user vulnerable to malicious packages. Note that "AUR helpers" are not officially condoned by Arch Linux, despite the system being unusable without them - officially you're supposed to examine all the PKGBUILDs of all dependencies manually to make sure they're safe.
I prefer the Void Linux approach - every "template" (equivalent to Arch's PKGBUILD) is kept in a single, monolithic git repository, and the barrier to contribution is kept low; just submit a pull request, and a core developer will review and accept it. This way all packages have binary builds and all packages have had at least nominal review, yet the repository is surprisingly broad. And if you need something that isn't in the repository, adapting an AUR PKGBUILD is trivial.
So true. There seems like there are competing packaging approaches, some claiming others are outdated while themselves say the opposite.
I've been willing to package a few of my open-source projects as well for almost a year, and out of frustration, I've ended up building my .deb packages manually and hosting them on my own apt repository. In the meantime, I've published a few packages on PPAs (for Ubuntu) and on AUR (for ArchLinux), and it's been as easy as it could have been.
Given I use Debian exclusively on my servers, it feels like a missed opportunity to me (not that I think my own projects are so much valuable to others, but I'd package a lot more stuff if it was clear how to do it well).