Should I use LUKS1 or LUKS2 for partition encryption?

As per the official draft for the documentation:

LUKS2 is the second version of the Linux Unified Key Setup for disk encryp- tion management. It is the follow-up of the LUKS1 [1, 2] format that extends capabilities of the on-disk format and removes some known problems and lim- itations. Most of the basic concepts of LUKS1 remain in place as designed in New Methods in Hard Disk Encryption 2 by Clemens Fruhwirth. LUKS provides a generic key store on the dedicated area on a disk, with the ability to use multiple passphrases 1 to unlock a stored key. LUKS2 extends this concept for more flexible ways of storing metadata, redundant information to provide recovery in the case of corruption in a metadata area, and an interface to store externally managed metadata for integration with other tools. While the implementation of LUKS2 is intended to be used with Linux-based dm-crypt 3 disk encryption, it is a generic format

Basically, although it's already available, it's quite a work-in-progress format by user/definition standards. Further citing the cryptsetup official release notes for the 2.0.0 version, barely 6 months ago (emphasis mine):

Cryptsetup 2.0.0 Release Notes

Stable release with experimental features.

This version introduces a new on-disk LUKS2 format.

The legacy LUKS (referenced as LUKS1) will be fully supported forever as well as a traditional and fully backward compatible format.

NOTE: This version changes soname of libcryptsetup library and increases major version for all public symbols. Most of the old functions are fully backward compatible, so only recompilation of programs should be needed.

Please note that authenticated disk encryption, non-cryptographic data integrity protection (dm-integrity), use of Argon2 Password-Based Key Derivation Function and the LUKS2 on-disk format itself are new features and can contain some bugs.

To provide all security features of authenticated encryption we need better nonce-reuse resistant algorithm in kernel (see note below). For now, please use authenticated encryption as experimental feature.

Please do not use LUKS2 without properly configured backup or in production systems that need to be compatible with older systems.

So, unless you need one of the new features, your best & most secure option would be going with the default/stable LUKS1. On the other hand, if you don't mind a bit of testing or issues with the setup, you can go with the LUKS2 option and report any issues you find to the cryptsetup issue tracker.

You should definitely use LUKS2 whenever possible. It is the newer header format and overcomes the limits of the (legacy) LUKS1 header. It is the default since cryptsetup version 2.1, but this alone doesn't say much. The Password-Based Key Derivation Function (PBKDF) is the big change.

If you use the PBKDF2 algorithm it doesn't really matter if you have a LUKS1 or LUKS2 header (even though LUKS2 is more resilient, as it has a backup copy of critical data). The newer Argon2i or Argon2id algorithms introduced with cryptsetup version 2.0 use up more space, which is why Argon2 doesn't fit into the smaller LUKS1 header.

Also, Argon2, as it is a newer algorithm, is probably even safer than PBKDF2, but it comes at the cost of more memory (RAM) consumption as well as requiring the LUKS2 header.

From the cryptsetup.8 manpage:

For PBKDF2, only time cost (number of iterations) applies. For Argon2i/id, there is also memory cost (memory required during the process of key derivation) and parallel cost (number of threads that run in parallel during the key derivation).

Since cryptsetup 2.1 defaults to the bigger LUKS2 header, it also seems to default to Argon2i instead of PBKDF2. I recently manually created a LUKS partition on my Debian Linux, current stable 10.4 (as of this writing; might have been 10.2 or 10.3 when I created the LUKS partition), and it was set to LUKS2 with Argon2i.

The problem is that GRUB2 doesn't support LUKS2 on most distributions (as of this writing), so a default installation will (have to) default to LUKS1 anyway, at least if /boot is affected, otherwise it cannot boot. There is this guide on how to do this properly on Debian 10 "Buster". Ubuntu is originally based on Debian, so it may be similar. The trick is to have a separate LUKS partition with a /boot partition on its own, and to convert this partition back to LUKS1 for GRUB2 to find the Linux kernel and initramfs. Alternatively the root partition, if it holds /boot and is LUKS2, may be converted back to LUKS1 in its entirety. In both cases it is a good idea to add a keyfile for one additional LUKS keyslot and to copy this keyfile into the initramfs (or configure the initramfs to find the keyfile). GRUB2 will ask for a password for /boot, but when booting the kernel and the initramfs, a password would have to be entered again - which is the same password for the same partition, if /boot is on the root partition (or another password for /, if it is different from the /boot partition). This can be avoided if the initramfs uses a keyfile, which is safely stored on the encrypted /boot anyway.

Also noteworthy: In January 2020 GRUB2 got a patch and is now able to handle LUKS2 headers, but only with the legacy PBKDF2 algorithm. There are two problems here. The first is that it takes time until such a patch comes into a release version and even more time until it is distributed. Debian 10.4 (stable-branch) for example has still an older version of GRUB2 which is unable to handle LUKS2. And second, Argon2 is not supported by GRUB2 even with the mentioned initial LUKS2-patch.

If you were to create a LUKS2 /boot partition, chances are high that it will default to Argon2i. For /boot you would have to specify --pbkdf pbkdf2 while creating a new keyslot for GRUB2 (with the LUKS2-patch) to make this work.

cryptsetup luksAddKey --pbkdf pbkdf2 /dev/<device>

I highly recommend reading the Arch Wiki pages for further information on how to work with cryptsetup and LUKS volumes.

As of January 10th 2020, GRUB supports LUKS2 so if you are using GRUB to unlock the /boot partition or encrypted disk - GRUB has you covered. As for features see Leo's answer

1. GRUB does not support LUKS2 yet. If your /boot directory is on a LUKS-encrypted device and you use GRUB as your bootloader, it won't work.
2. [minor point] Older cryptsetup (1.x.y) can't process LUKS2, so Live CD/USBs with a version of cryptsetup before 2 can't be used to decrypt LUKS2 partitions.