Support

As written on that page:

Note: Some people assert that moving wp-config.php has minimal security benefits and, if not done carefully, may actually introduce serious vulnerabilities. Others disagree.

I belong to those who assert that moving configuration files around –be it Joomla! or WordPress– has no security benefits. As long as the application can read this information so can a hacker. THe only thing it would protect you would be a known file location dump vulnerability but, in this case, you only stall the hacker, not deter them. Instead of 1 request they will need two (WP) or three (Joomla!).

In any case, what you describe is a bug in Akeeba Backup for WordPress because I anticipated this situation and I'm supposed to be handling it in the CLI scripts. Please download the latest dev release from https://www.akeebabackup.com/download/developer-releases/backupwp-dev.html

Technically, Joomla! aso allows you to move the configuration.php file around. In fact, it allows you to place it anywhere in the filesystem. You just have to change the JPATH_CONFIGURATION define in defines.php in both back- and front-end. It's my conviction that this does not offer any security benefits and the cost of devising, documenting and maintaining a workaround for this practice in Akeeba Backup is unjustified and overcomplicated. The same applies for Akeeba Backup for WordPress and wp-config.php

The only support offered in both cases is that when the backup is run from inside the CMS we are supposed to be able to read the configuration file and complete the backup. The configuration file itself will NOT be included in the backup by design. The only files added in the backup are those under the site's root and any extra directories you have specified unless you have explicitly excluded the directory or file. Yes, there is a reason for that.

Let's say that your source site is on a typical cPanel shared host. Your files are inside /home/foobar/public_html and your configuration file is inside /home/foobar (one level above the root). You take a backup and you restore it to an Ubuntu Server with stock Apache configuration, meaning that the files must be written in /var/www. Note that for security reasons only root can write to /var and there is no /home/foobar directory because your user in Ubuntu is called baz, not foobar. We have the following options when extracting/restoring the backup archive as far as the configuration file's placement, ranging from bad to despicable:

• Try to restore using the absolute path (/home/foobar). The directory doesn't exist, the extraction fails and the backup archive can no longer be restored to any server.
• Try to restore using the relative path (../). The directory in question, /var, is not writable, the extraction fails and the backup archive can no longer be restored to any server.
• Restore the configuration file inside the site's root, or in a special directory (like off-site directories). This makes it mandatory for the user to read the restoration documentation before he can make the site work. Moreover, accurate instructions to handle this situation cannot be written making it impossible to tell the user to read a documentation page about it. Each site setup would need its own set of instructions. That's impractical.
• Not extract the file at all. In this case, why expend the energy to make engine and archive file format changes (which cause a domino effect in half a dozen software and as many documentation books) to accommodate for the file which will typically not be extracted when you can simply not include it at all?

So, yeah, while both CMS allow you to move the configuration file around your server it's not a good idea. Just because you can doesn't mean you should.