Well, after researching the topic RPM compression much more in-depth than originally intended, I can come up a conclusive suggestion.
but the information from @adekker above is important for packagers who provide packges for older SFOS versions.
I do not see that anybody questioned that, rather the opposite: Jolla’s and @dekker’s information, plus your “non-suggestion” made me research and document this.
I guess setting the compression scheme back to the previous one is a feasible approach for such packages.
Well, “the previous one” is not really conclusive (see my prior post), and I do think that RedHat’s / Fedora’s former choice of xz -2 -T (= %define _binary_payload w2T.xzdio in the spec file) is a better fit for large RPM files (> 100 kbytes), especially for mobile devices. Only for multi-megabyte RPMs I would choose (at most) xz -6 -T (= %define _binary_payload w6T.xzdio), but do understand that Jolla had chosen this as a “one size fits all” setting, because it covers the worst cases well. Note that multithreading for the option -T was introduced in xz 5.2.0, hence it cannot be used for RPMs which may be installed on SailfishOS < 3.2.0!
For small RPMs (< 100 kbytes) and all SRPMs, gzip -9 (= %define _binary_payload w9.gzdio and %define _source_payload w9.gzdio; the latter seems to be the default on most Linux distributions including SailfishOS) is absolutely fine, even its default compression level 6 is almost equivalent (and compresses much faster) and in some cases even 1 (but not 0, because it means “no compression”).
P.S.: On SailfishOS ≥ 4.5.0 Jolla exactly followed RedHat’s / Fedora’s choice of zstd's compression level 19, which is a reasonable as a general default setting, because it covers the worst cases well. I would add (in line with Jolla’s former choice for xz) the parameter -T (= %define _binary_payload w19T.zstdio), which defaults to 0 if -T is set, and to 1 if not (see man-page). For RPMs < 1 Mbyte zstd -10 -T (= %define _binary_payload w10T.zstdio; at most 15) appears to be a better choice. Note that zstd's default at the command line is a compression level parameter of merely 3, but that was likely chosen because of its much faster compression speed, which is much nicer for interactive use (though the compression ratio is lower and decompression slightly slower).
But as the switch to zstd with the backward compatibility issues it causes was the principal point here, xz and / or gzip are the proper choices to obtain backward compatibility.