In the scenario of the question, the cryptography involved on the server side will be, for each client connection, and ignoring a number of details like random number generation
- Diffie-Hellmann in some group for the generation of session keys
- Few SHA-512 as part of that, of relatively negligible computational cost for competent implementation, assuming 1 is in software (or if 2 was in hardware)
- Some AES-256 cryptography, as part of packet exchanges, also of relatively negligible computational cost for competent implementation, usual packet size, assuming 1 is in software or 3 is in hardware (including using AES-NI of modern x86 CPUs)
- Some other untold assymetric crypto operation (like a few signature verifications), especially if the clients are authenticated by assymetric cryptography; I'll leave that alone, but it could be significant, even dominant.
The groups in the blog post quoted in the question seem to be that of RFC 5114 section 3.2. I thus believe that the blog post makes a serious error when it ranks group 24 as "Next Generation Encryption" and more secure than group 19 ranked "ACCEPTABLE". Group 24 seems to be a Schnorr group with $p$ of 2048 bits and $q$ of 256 bits, quoted as giving 112-bit symmetric security where groups 19, 20 and 21 would be 256-bit, 384-bit and 521-bit elliptic curves with 128, 192 and 256-bit security (taking 192 and 256-bit security with a grain of salt as anything above about 160-bit in that sense could be attackable, with humanly sizable odds of success, only if there was a totally disruptive breakthrough, like quantum computers usable for cryptanalysis; or, regardless of security level, if there's some goof or backdoor in the implementation).
On a nearby VM with openSSL 1.02g installed and
lscpu reporting 2 cores at 4 GHz, the command
openssl speed reported what could be a passable benchmark for groups 19, 20 and 21 as implemented by openSSL (the last colum is mine, and I have slightly edited the others for legibility)
256 bit ecdh (nistp256) 18190 op/s (group 19)
384 bit ecdh (nistp384) 1980 op/s (group 20)
521 bit ecdh (nistp521) 2834 op/s (group 21)
I'm surprised that nistp521 is shown faster than nistp384; think of it as an illustration that timing varies enormously with the quality of the software implemention (and perhaps, different parameters in benchmarks, which I have not cheked). But these numbers tell us that the 2500 clients reconnecting simultaneously are unlikely to take more than a few seconds of CPU time for the crytography in 1 (thus in 1/2/3), with a competent implementation in software on a powerful x86 CPU, for groups 20 and 21; with group 19 significantly faster (and, as far as we know, unlikely to be an exploitable weakness anytime soon; compromize of the server or its private key is a much more down-to-earth concern).
Beware that an "ipsec concentrator/gateway" typicaly will use something much lesser than a powerful x86 CPU; on the other hand, some have crypto accelerators. The most important thing is how good and trustable is the software; and that's impossible to tell from specs.