In some cases, shedding requirements is good. In most, it is just a race to feature parity. :(
RPM is a solid, mature, heavily used package format. And the .spec file I've always found to be so much easier to work with than Debian packaging. I've made many debs, and my current work uses debs for deploying all our software, but I still find it so much harder to make them. I have a workflow for my current packages, but if I want to take a new piece of software and turn it into a .deb, it is always pretty painful. I usually have to ask a debian packager for help. They are always super nice and helpful, but I just wish I could package things myself.
Seems like if you package .debs all the time, it becomes easier. But as an infrequent packager, I find RPMs .spec to be much easier to manage than Debian's system.
Ports systems like alpine/arch/void are nice, but they also handle less (except for void maybe, that ports system has built in support for a lot of different build systems, so packaging a cmake or meson project is a breeze).
It's actually possible to use RPM spec files to build Debian packages: https://github.com/debbuild/debbuild
And I've been going through and slowly porting much of the RPM ecosystem common macros to run on debbuild so that spec files can be reused to comply with Debian packaging policies as much as possible: https://github.com/debbuild/debbuild-macros
(Disclosure: I'm the current maintainer of debbuild)