The output that is mentioned here and in the release notes actually comes from subwasm and is internally called by srtool.
Historically, srtool used a sha256 to compare WASM runtimes. While it worked for the comparison, sha256 in that context was rather useless and has been removed. It has been replaced by the
system.setCode hash which is the scale encoding of
<module> / <call> / <data> so in our case
system / setCode / runtime.
While also usable to compare runtimes,
system.setCode is much more useful and has a direct use since it is also the one required to propose a runtime upgrade on a relay chain directly. It became the de-facto hash that represents a runtime.
The IPFS hash is rather unrelated but convenient as it allows fetching the runtime from IPFS if this runtime is seeded. srtool and subwasm do not seed the runtime on IPFS but compute the hash of the data. So if one or more users seeded this runtime, you can easily fetch it using https://ipfs.io/ipfs/QmVqUxwE8zoCZrxVM4nHEQPuQKfZyCMPS65hfojEY3EdME for the hash mentioned in the OP.
The 2 other hashes (
authorizeUpgrade hash and
Blake2-256 hash) are utilities that ease the creation of more complex proposals mainly related to sending parachain upgrade messages from the relay chain.