An RFC for Argon2 has been published now, which provides several recommendations. Unfortunately, the situation is still not clear cut and seems unrealistic.
Their two generally recommended options are:
If a uniformly safe option that is not tailored to your application or hardware is acceptable, select Argon2id with t=1 iteration, p=4
lanes, m=2^(21) (2 GiB of RAM), 128-bit salt, and 256-bit tag size.
If much less memory is available, a uniformly safe option is Argon2id with t=3 iterations, p=4 lanes, m=2^(16) (64 MiB of RAM),
128-bit salt, and 256-bit tag size.
However, directly above that they state:
Argon2id is optimized for more realistic settings, where the adversary
can possibly access the same machine, use its CPU, or mount cold-boot
attacks. We suggest the following settings:
Backend server authentication, which takes 0.5 seconds on a 2 GHz CPU
using 4 cores -- Argon2id with 8 lanes and 4 GiB of RAM.
Key derivation for hard-drive encryption, which takes 3 seconds on a 2
GHz CPU using 2 cores -- Argon2id with 4 lanes and 6 GiB of RAM.
Frontend server authentication, which takes 0.5 seconds on a 2 GHz CPU
using 2 cores -- Argon2id with 4 lanes and 1 GiB of RAM.
Most of these memory suggestions sound unusably high to me. In contrast, the libsodium documentation says there's no 'insecure' memory size but obviously encourages more when possible.
For servers, you should probably opt for server relief to avoid DoS attacks. This involves both client-side and server-side hashing, potentially allowing slightly larger parameters on the client. However, the client-side parameters might have to be limited due to things like mobile devices.
I personally wouldn't go below 32 MiB and would consider 64 MiB a better minimum. However, it should be adjusted based on the hardware/clients for the best security. More memory is better than more iterations.
Update - 09/01/2023
Steve Thomas, one of the Password Hashing Competition (PHC) judges, maintains a page with minimum settings for multiple password hashing algorithms, including Argon2. At the time of writing, this is more up-to-date than OWASP recommendations.
Also, in a server context, consider using bcrypt (ideally hmac-bcrypt) instead of Argon2. bcrypt is minimally cache-hard, so it offers better protection at shorter runtimes than Argon2, which is more suited to key derivation like scrypt.