I prefer the VPN way. It saves a lot of CPU/RAM resources since your WP will not execute checking for valid IP connection which causes some I/O, RAM, CPU resources.
Using the VPN limit IP approach you to save some resources. Once Apache found that the connecting IP is not allowed. It will drop the connection thus saving you some CPU cycles (checking MySQL) and some RAM which can be used to serve other visitors.
Enabling MAX mode is like UAC in Windows, it’s an added layer of authentication to restrict file uploads that’s enforced by traditional DAC permissions in the OS. Splitting permissions between the account owner and WP user makes it easier to establish audit trails, i.e. if a file is uploaded within WP directly without using FTP/SFTP, it’s tagged with a different UID than if it gets uploaded using FTP (Fortification mode on).
There’s a feature in the panel aptly called “Audit” that generates a list of such files or directories that have lax permissions.
On that topic too applying rules to deny PHP execution of /wp-content/uploads, /temp, and other media locations goes a long way in stymying drive-by hackers. Something as simple as this would work assuming mod_php,
In addition having some form of brute-force protection in front of /wp-login.php or any high-value URI (/xmlrpc.php also) is good insurance as those are typically abused. I run protection with a lower threshold against these URIs.
Most mod_security rules are overkill and getting applied non-deterministically to all URIs only hurts performance. One nice feature is the ability to pass all file creation to a third-party binary like ClamAV to determine if it’s clean. You can proactively block malware before it makes its way onto the server assuming another tool like fail2ban bans these IPs before they can do further harm.
Set reasonable worker limits and monitor outages through something like Monit. Limits are intended to prevent resource monopolization and alert you of extremes. Having 20 PHP-FPM pool processes on a site that normally uses 1-2 concurrently makes it too easy to mask problems.
WordPress plugins like WordFence that rely specifically on WordPress to work happen too late in the processing axis to be viable. If it’s all that you have, then it’s better than nothing, but in most single-user setups compromising one file elsewhere would allow an attacker to compromise WordFence. The only thing worse than being insecure is having a false sense of security. There’s performance concerns with it beyond this scope as well.
Above all the most important pieces of the puzzle:
Always keep your plugins and themes up to date. If a plugin or theme doesn’t work with PHP 7.4 but does with 7.3, then it’s time to junk it as this hints at deeper problems in craftsmanship of that product. You wouldn’t buy a house from a carpenter that only leaks when it’s raining.