The tradeoff you get with other distributions being quick, is less quality assurance. Also, Debian still has a policy of working on 10 architectures, and this slows things down significantly sometimes. The other distributions you mentioned don't have this constraint.
The crux of the problem is that all current official Debian packaging methods supported by Debian are sufficiently arcane and obtusely documented to the point that it's a high barrier to entry for people to do it right.
Personally, I've been doing RPM and Debian packaging for over a decade now, and it boggles the mind how much more complicated doing _correct_ Debian packaging is for essentially the same that happens on an RPM distribution like Fedora or openSUSE.
One of the reasons that I started using debbuild[1] for building Debian packages years ago was that I felt like I could get something that closely resembled a policy-compliant Debian package without impossible amounts of guesswork. Combined with macros adapted from Fedora and other distros[2] as an interface for Debian packaging policies, I can package things rather easily for Debian/Ubuntu using the much more straightforward guidelines from Fedora as a base.
As it turns out, it doesn't take that much effort to make packages that comply with Fedora/openSUSE Packaging Guidelines and Debian Policy with this tool, and it has drastically simplified my ability to maintain software across distributions in a way that still cleanly integrates with the distribution platform.
I wish that debbuild would be an officially supported mechanism in Debian, but it's probably unlikely without a Debian Developer advocating for it (and I suspect no one there would, as they probably like the existing system...).
[1]: https://github.com/debbuild/debbuild
[2]: https://github.com/debbuild/debbuild-macros
(Disclaimer: I am now the current developer of debbuild and debbuild-macros, though I wasn't when I first started using it)
Simply throwing a bunch of files into a package or a container is very quick.
Making an official Debian package is not supposed to be quick. DDs thoroughly review and test the software they are packaging. While packaging I often chase missing licensing information, find plenty of bugs, write systemd unit/init files and sandboxing, write manpages, functional tests, and sometimes find serious vulnerabilities.
I worked on various packaging and deploying systems, and most other distributions don't come anywhere close to this level of scrutiny.
I should also add that becoming a DD requires years of commitment and proven track record of work.
The next time someone complains that making a container is very easy in comparison they should ask themselves: how much can I trust a software source with a very low entry bar?
I dare say, if Ubuntu is any indication, Pacman packages consistently feel higher-quality than deb packages. Unlike on Ubuntu, on Arch, you can actually update your packages without breaking something...
Can you clarify what do you exactly mean with this?
Also... look at that guide. Why is it so difficult and obtuse? Why do I have to run so many odd tools, including apparently modifying some file in /etc and running other stuff as root? In contrast, this was my first contribution to Nixpkgs: https://github.com/NixOS/nixpkgs/commit/0b8efd8724e59964bad0... Easily as reproducible as anything Debian, and apart from installing Nix it didn't require any funkyness in the build environment. I tested the definition by running 'nix-build . -A oclgrind' in my checkout of the Nixpkgs repository. I managed this after running NixOS for two days.
This is the same software that I also contributed to Homebrew: https://github.com/Homebrew/homebrew-core/commit/1268459f761... Again, a simple declarative-ish package description (written in Ruby, which is not my favourite, but it's better than the weird Makefile/shell amalgamations that are used by DPKG and RPM).
Both Nix and Homebrew have serious limitations compared to Debian (Homebrew in particular is aggressively limiting its scope to gain simplicity and in particularly doesn't care as much about reproducibility). But as a user, I must admit I have not missed what Debian provides that these do not. Whenever I tried to package stuff for Debian, I felt that I was paying a tax for unclear gain. It's a shame, because I like Debian for over a decade, and I am strongly sympathetic to the idea of the project in principle.
I agree that Debian packaging is difficult/odd/arguably obtuse; I guess it's a legacy matter. Your phrasing can be interpreted as if the guide itself is obtuse, it's not clear :)
> including apparently modifying some file in /etc and running other stuff as root?
It's important to read and understand it fully. Anything you do it as root is required only to run a preview build locally. This is an optional step, so no, one doesn't need to perform admin configurations/operations if they don't want to, although performing a local build is a desirable step.
> In contrast, this was my first contribution to Nixpkgs
This is not a proper comparison, as you're comparing an entirely manual procedure versus using a packaging tool.
A proper (closer) comparison is probably against the tool that the guide references: https://github.com/saveriomiroddi/ppa_packaging, where you just declare all the metadata, and invoke a script that takes care of everything.
All in all, I'm personally puzzled about why there aren't tools around to simplify/automate Debian packaging. I've started the small tool mentioned above (`ppa_packaging`), but I'll likely not continue working on it, as my experience with niche projects is that, while useful in their (narrow) domain, they're very resource-intensive to maintain.
I mean Debian packaging is a terrible pain - but I have to have empathy with the fact that it's a technical system and more importantly an online community that's been doing it's thing since 1993.
The fact is that with such a long-running system there's more than one way to do everything.
The way we discuss/learn technology has also partly changed. Most of the documentation for Debian is extensive manuals - there's "not enough" intro text, and then "too much" detailed documentation
And then there's the "cost of change". Lots of Debian developers have been packaging using their particular versions of tools for a long time and are happy with them.
In many ways Debian works because the people working on it care about quality and the tooling is second order to the efforts they make.
In contrast, I managed to submit software to Homebrew after two weeks of macOS, and to Nixpkgs within two days of running NixOS.