I don't think that the tediousness of a given task is sufficient to determine adding new features, particularly if it's not something that a human that has to type it completely by hand. Novel things that are completely impractical to represent (not merely some repetition) are more interesting from that standpoint.
I'd have a few concerns on this. Firstly there's the syntax question, this would be adding brand new semantics to the PromQL language just to avoid using templating from your configuration management system (or being smart with round and count_values, or quantile/quantile_over_time depending on what output you want).
Secondly, this would be a significant cardinality explosion risk. Right now the most you can ever increase cardinality with PromQL is via absent, and that's only from 0 to 1. This would allow you to multiply the cardinality of the input by the number of buckets - and that could get big fast, especially if we've fancier histograms in future. From a general safety/resilience standpoint I consider this an important property of PromQL.
Thirdly if the concern is indeed tediousness, then what if the user isn't happy with explicitly listing each individual bucket and wants linear/exponential options? That'd add even more functions to PromQL, and even more of a cardinality risk.
I can see the potential uses of this, but the overall complexity plus the cardinality risks do not seem like a good tradeoff for something that's already completely possible today. I don't think trying to remove all repetition/tedium from PromQL queries via changes at the PromQL level is a good strategy, and solving such things at a higher level on top of PromQL is a better option.
Brian