To counter that with my anecdata, my Debian installations usually outlast the hardware they've been built on. I've found that it's much easier to start new builds with a backup (or the original disk) of the machine they're replacing, that's how easy it is to maintain a Debian system for me.
Heck, my first Linux desktop started out as Ubuntu Breezy, and ended its life as Debian Squeeze. Its replacement started out as Debian Wheezy, and is now on Bullseye.
There are other options. For example, you can sit on stable and get specific packages from unstable, so long as they don't have dependency conflicts with the rest of your system. It requires a little more thought than just running with the defaults, but the docs are pretty clear and detailed (man apt_preferences), and it's mostly a one-time operation. I do this with docker, the kernel, and a maybe a couple other things.
> And if you have a Debian machine that’s a couple years old and you want to upgrade it to the latest Debian version? Good luck.
I guess I'm among the others here who have had good luck, then. The first counterexample that comes to mind is a NAS appliance that is now around ten years old. I replaced its stock OS with debian stable (Squeeze, maybe?) and ran it that way until a year or so past the next stable release, then upgraded. It went fine. I did the same thing repeatedly over the years, until finally decommissioning it last month. It now runs Buster, so that's at least four major version upgrades done past their expiration dates. None of them gave me any trouble. The only thing wrong with it is that my needs have outgrown the hardware.
Of course, Debian doesn’t require manual intervention for most updates, but it also isn’t rolling release. If you want packages that are actually recent you have to sit on Sid, which is a lot less stable than Arch. And if you have a Debian machine that’s a couple years old and you want to upgrade it to the latest Debian version? Good luck. Some of that isn’t Debian’s fault, but whereas on Arch major, breaking package changes are rare but irregular, on Debian they tend to hit you simultaneously in one major upgrade. For home machines, I definitely prefer an occasional manual intervention and continuous fixes over major breakages every couple years where I often just give up and reinstall from scratch.
That said I use Arch a lot less nowadays as I’ve moved onto NixOS. Nix is clearly headed somewhere new, though it remains to be seen if the complexity of the approach is actually maintainable.
If I want to make an idiomatic Arch package, it’s usually easy: PKGBUILDs are intuitive and simple. Nix is much the same for most stuff, especially since most of the boilerplate for various build systems has been automated; though for a program as complex as Kubernetes its a nightmare, to be sure. For Dpkg though, it seems like so much complexity, and I don’t think I ever really had a good experience.
And honestly, I have no idea how to make an RPM package anymore.