OK. In this case, I believe having it shipped as the default (or recognized) compression filter might be a little bit tricky. I am not sure if Qubes OS core team would approve any software in copr due to security concerns. But there is still hope. It might be possible to contact Fedora packaging team (e.g. via their Matrix channel) and query about the status of that package.
Having said all of the above, I believe that the chances of having it in Qubes OS r4.3 is slim. As it should take some time for it to be transferred from copr to testing and stable repositories.
By default, the recognized compression filters are hard-coded here. And backup GUI will show those filters which are installed. But it is possible to use the CLI with any filter. It is also possible to trick the Backup GUI with the bash executable at ~/bin (for example ~/bin/xz could point to /usr/bin/plzip.
Is this advantageous? If so, “pigz” sounds good: it brings in the good old gzip utility and with multiple threads execution (at least for compression, which is where most of the user wait times exist anyways (I backup more times than I do restore))
We should also have the “no compression, dammit” option; I care less how big backup images are than I do that they take too damn long.
What is critical is that the installer USB image have filters installed for all choices listed in the backup GUI. It would be actively harmful to present alternatives that the latest installer does not know how to read.
Most of those in the current list and in the proposed patch are worse than pointless, as they are fatally inferior to modern methods. It would suffice to offer only “none”, “zstd” (small, fast), and “lz4” (small enough, even faster), defaulting to as much parallelism as the machine can provide. (“Lz4” might be even be faster than “none” on many SSDs.) To me this is the highest-priority improvement proposed because it affects everyone, enables hours and hours of time saved, and, most important, would cause backups to be done more frequently.