Support

What you are looking for is called Administrator Password Protection. It's a different feature, implemented at the web server level, it resutls in a 403 when the attacker fails authentication, and it uses far less resources than the secret URL parameter.

The problem you have is that by using the secret URL parameter to block brute force attacks requires your server to go through the .htaccess file, spin up a PHP thread, have PHP process several hundred of PHP files which make up the minimum Joomla! environment and system plugins, perform a number of database requests, and only then do something with the request. It doesn't matter if the result is an HTTP 40x, or a 30x. This is where the bulk of your server resources waste is, not the redirection. Even in the unlikely case you are being attacked by brute force scripts which follow redirections, implementing a 40x response would only halve the waste of server resources. Using an administrator directory password would reduce the waste of server resource by two orders of magnitude.

As you can see, I really do understand your use case and I am trying to guide you to an effective solution to your legitimate and very real problem. I can very easily add one more option to let you choose whether the secret URL parameter will be redirecting to home, or just stop with a 403 error. That's easy; a five minute job which will take me less time than writing this reply. I am not trying to avoid work, I am trying to give you a solution to your problem. If you insist, I will of course implement this feature for the next release, but do keep in mind that it won't do much to help you with your problem. The alternative solution I gave you can be applied today and it will actually solve your problem. Of course, it's your site and your choice. I just want you to know why I proposed a completely different solution. It's not because I don't want to implement your suggestion, it's because I know for a fact it won't help anywhere near as much as you think it will (I have run benchmarks with ab, the Apache Benchmark tool, against development and real world servers, the latter always showing a bigger delta between the two solutions due to the higher iowait from other sites / VMs on the same host machine).

No worries! I've already implemented your suggestion; I told you, it was a 5' job :)

Now, about backend vs frontend and protecting logins. Do remember that Joomla! allows you to connect to both frontend and backend with the same username and password. If certain frontend users have editing privileges they are almost as sensitive as users with backend access privileges -- remember that Super Users can even change some site configuration parameters in the frontend! I would definitely recommend using Joomla's Multi-factor Authentication to force the use of MFA for these user groups. Fun fact: Joomla's MFA was called Akeeba LoginGuard; I contributed it to Joomla! a couple of years ago to make sure all Joomla! users get the same high level of protection we and our clients did.

Regarding the backend, I am not sure if you are running your own servers or you're using commercial hosting. If you run your own servers you can disallow access from public IPs and limit backend connection through a VPN. The hardest part is setting up the VPN. Limiting access by IP range is very easy using .htaccess files (Apache, LiteSpeed), web.config files (IIS), or server configuration (NginX). This works far better than country geofencing which is neither perfectly accurate (you get at best 95% accuracy for both false positives and false negatives), nor does it address the use case of admin account holders traveling abroad.

Speaking of VPNs, there's always the obvious use case. You can set up a virtual machine on a VM provider (e.g. Akamai/Linode, DigitalOcean, Amazon EC2, ...) with a static IP address on the Internet and run VPN and/or proxy software on it. You can then limit access to sites' administrator only to the IP of this intermediate server (it's not quite a jump server), and have all clients VPN into it, or set it up as a proxy -- whatever works best for your use case. This automatically cuts down all the admin brute force attempts on your sites at the expense of a bit of a fuss to connect to the site's backend.