The life of a package distributor is one of constant build changes. Among them, the switch from autotools to meson is probably not an especially disruptive one. For the ecosystems I've helped maintain, it certainly wouldn't be.
Packaging frameworks like Debian and RPM coevolved with autotools, especially when it comes to things like cross-compilation, standard build flags, etc. Anything that moves away from autotools is, AFAIU, generally considered a PITA for maintainers of the big distributions. Modern build tools optimize for the problems of massive corporate centralized repositories and build pipelines, which often bundle dependencies and otherwise approach most problems from an entirely different angle. Nuances related to portability, cross-compilation, filesystem hierarchies, dynamic library versioning, etc, are typically afterthoughts if they're considered at all.
OTOH, while it's a PITA it's certainly one to which package maintainers are accustomed. autotools began to lose mindshare among younger programmers and with younger projects many years ago.
IME as someone who has done alot of portability work, both for my own projects and others, and including writing more than my fair share of Debian and RPM builds (but not as an official package maintainer for a distro), boilerplate stuff is rarely the issue. It's all the random, niche problems that invariably crop up at least once or twice with every project, even smaller ones. Every build is broken somehow. Given that basic reality, what matters is how often you can route around brokenness without patching the upstream build, and when you must patch how easy it will be to implement and maintain those patches.
