Write-benchmark of gnome-disks

While you could test all of those independently I would recommend the Phoronix Test Suite.

From the Site:
The Phoronix Test Suite is the most comprehensive testing and benchmarking platform available that provides an extensible framework for which new tests can be easily added. The software is designed to effectively carry out both qualitative and quantitative benchmarks in a clean, reproducible, and easy-to-use manner.

The Phoronix Test Suite can be adapted to run on platforms ranging from smartphones and personal computers to multi-core workstations and cloud computing infrastructures. (VM: essentially cloud)

Extensible Architecture: The Phoronix Test Suite ships with more than 130 test profiles and 60 test suites. These tests range from battery power consumption monitoring for mobile devices to multi-threaded ray-tracing benchmarks and span the CPU, graphics, system memory, disk storage, and motherboard components. If there is a test though not currently covered by the Phoronix Test Suite, new tests can be quickly added via its extensible architecture (see documentation) with each profile just being comprised of XML files and a few simple scripts.

Edit:
Note: I have never used the product only been told about it recently from a friend who did. He had some MySQL specific tests that he wanted to do that (according to him) no benchmark could do. He knew what to do for the test and was able to use their framework to integrate the tests he wanted.

Phoronix Test Suite: Home Page
Phoronix Test Suite: Features

KDF speed is important, but contrary to your belief, it should be SLOW.

With LUKS, your encrypted drive contains a header with an encrypted master key that is used to encrypt your device. This master key gets decrypted with one of the keys in your key slots when you boot/open the device (try cryptsetup luksDump /dev/sdx to see information contained in the LUKS header).

When you first format the LUKS device, it will ask you for a passphrase (or keyfile). This passphrase is then used to create and encrypt a key that will be added in keyslot 0. Your passphrase is also hashed and stored, so that LUKS can verify if you entered the right passphrase when you open the device. This is important to understand, because if you use a fast hashing algorithm, it is easier to crack the passphrase since an attacker can test a lot more combinations in shorter time.

Therefore, you should go for the slowest and most secure hashing algorithm (sha512 or whirlpool) and use a high --iter-time. The --iter-time option allows you to set the time it takes to do 1 hashing iteration. The only downside to a high iteration time is that it takes just that long to actually open the encrypted device. Say you use an --iter-time of 10000 (10 seconds) on your root device, then it will take 10 seconds for your system to get the actual encryption key and thus you will have to wait that long after your password before booting continues. This only happens once when you open the device, so further performance is not affected.

For your actual encryption cipher, it depends on how fast your underlying physical device can read/write and how much workload is on the machine. The encryption/decryption is performed by your CPU, so if you go with the slowest one there is a good chance that it will affect other programs running at the same time. As of right now, aes-xts-plain64 is considered the most secure LUKS cipher, so if you have very confidential information you should probably go with aes-xts-plain64 and a keysize of 512 (since with xts the key is split in 2 so you actually get aes with 256-bit keys).

If I were to make a recommendation on your setup, it would be sha512 as hashing algorithm with an iter-time between 2s-10s and using aes-xts-plain64 with a keysize of 256, since AES-128 is still considered secure.