When it comes to security software for Wordpress, such as Wordfence and Malcare, my first objection is that such Plugins tend not to be free; or someone might decide to buy the "premium" or "pro" version, which tends to complicate the website implementation and make it harder to maintain for developers. Of course, that is also a problem with many other popular Wordpress plugins, including Advanced Custom Fields Pro, but my point is that it tends to make it more difficult and tedious for developers to work with the website.
For example, when I get a Wordpress job, I often battle with these paid plugins, since I do not have the license keys or necessary access to update them. Extra time is spent e-mailing the client to get the keys; sometimes the client might also have thrown away the "keys", and, more rarely, they might not even know what these plugins are, or why they are installed. Etc. This is a general problem with Wordpress. Often a client will also install something they do not really need, because that is what "was recommended to them", and it can be hard to convince them otherwise.
When I studied Multimedia design at KEA in Copenhagen, students were told to install Wordfence — or at least introduced to it — this is, of course, mostly a front-end orientated education, so it may be justifiable. But, obviously the best approach to security is to make sure your system is secure from the start; unfortunately, with Wordpress, and third party plugins, that is something that is very difficult to do. You could probably scan the code for certain PHP functions, and then analyze how these are used — but few people do that.
A less talked about subject is the fact that some Plugins might "phone home"; this might share confidential information about your implementation or personal information about your users and visitors to your site with the developers of the plugins.
Securing a Wordpress site
The question is, when you rely on third party plugins and themes, how do you secure your site? The answer is that you typically do not. There is no reasonable way to know if there is some unknown backdoor in the code that might allow someone to read the entire database and file system. Even worse, someone might gain write-access to the file system and thereby gain full control over your website. Wordpress core is often said to be more tested and secure than third party plugins, so, one way to go about it might be to limit your use of third party plugins and themes.
Should you rely on Wordfence to create an extra layer of security? Well. Wordfence does have a free version, so it is probably not going to do any harm, given you trust the developers — but, I would not rely on these security plugins as my only defense, and preferably I would not install them at all.
I have sometimes installed a security plugin on client-websites, on their request, or in order to save time. To me this is always a short-term solution — but it is surely better than nothing.
As a developer with a lot of back-end experience, I would do other things to secure a site.
Disable Write Access to certain files and Directories
Just like in an operating system, system files should not be writable by all programs running on the machine. If you disable write-access to certain files and directories after fully updating the system, you will probably prevent the majority of hacking attempts from succeeding. This will not protect against vulnerabilities that gives a hacker access to database input/output — but those should be more rare, and probably less severe in most cases.
The problem with disabling write-access is that your site becomes harder to update, since it might force you to use a command line tool like WP-CLI when updating — alternatively you should remember to re-allow write access before you update. Doing any of this incorrectly could slightly break your site, so be very careful, and be sure to take backups.
Generally, it should be safe to disable write-access to the plugins and themes directories. But, Wordpress needs to have write access to some directories, including the uploads and backups directories, since users might write to these locations. You should not make it impossible for users to upload files entirely — maintaining some write-access is okay, and actually expected.
Also, sometimes you might encounter a plugin that writes data to its own directory — even though this is a bit of a bad-practice — so you should carefully test which file permissions work for your system.
Disabling write access is not enough
Websites that deals with customer data should of course fulfill the relevant privacy laws, but more importantly, it should be secured from the back-end — that means, you should generally avoid front-end security software such as Wordfence and Malcare — they are no substitute for actually securing your site.
What does this mean? In extreme cases, it could mean your developer opts to not use third party plugins from little known authors, and keep sensitive customer data on a separate server — or at least encrypt the data as an extra layer of security. The fact that a hacker has gained access to the database does not necessarily mean they also got access to reading the file system — so if the data is encrypted, it will most likely be completely useless to hackers.
Realistically, such setups are probably not going to happen for most smaller businesses. But, this just highlights the complexity of the problems Wordpress developers are facing. Security is not easy — it is very hard!
Security plugins for Wordpress are a bit like Antivirus for Windows, they do not guard against everything, and often you will be fine without; but, you do need to have some idea about what you are doing! Wordfence is still fine if that is all you got — but you should also know that it is probably not sufficient to keep you protected.
As developers, we may find it hard enough to secure our own code, introducing other peoples code into our systems is only going to make the situation worse. The best approach is probably to assume that your system is insecure, and be prepared just in case something does happen.
Some web hosts come with their own server-sided security, if you prefer not to have anything to do with servers, then you should look for a web host with brute-force protection or similar; be careful, and only pick a web host with a proven history of reliability and security for important websites.
If you are comfortable with Linux servers yourself, then you may want to take a look at tools like fail2ban and mod-security, as these can be a helpful extra defense against hackers. Managing your own web server is a lot of fun, and is actually not hard once you get started; Linux is very user-friendly in this area, as all it takes to run a server, usually, is to type a few commands in terminal, and you will have a working server.
fail2ban will automatically ban IP addresses if they are misbehaving and attempting to brute force a server login. It comes with a number of template configurations, and is fairly easy to learn how to use. When I tried setting it up the first time, it probably only took me a few hours to understand how to use it.
This is of course not a grantee that you will never be hacked, but it will limit any success that hackers might otherwise have had with silly brute-force attempts. It might even block some comment spam in the process.
Always prepare for the worst
It is very hard to create a website that will never be hacked. This does not mean that we should lean back and accept the fact that we probably will get hacked — there are many things we can do to mitigate the damage from successful attacks, and often even prevent them entirely. What matters is that we at least put reasonable efforts into these things.
Taking regular backups of your website is a very effective tool in recovering from successful hacks, and probably a absolute minimum requirement. But you should really not allow it to get to this point. If a hacker has gained access to the database, sensitive data could be leaked to the internet, and that is potentially a far worse scenario than having to "just" restore your website after a hack.
According to data protection laws such as GDPR, you might also be required to inform your users, as well as relevant authorities, that you got hacked — not doing so could result in fines — you might want to seek legal advice about this subject as it is fairly complex. I am not an expert in this area, but know enough about it to warn people that it might be a problem. I have often had smaller clients that seemed totally unaware about this. So please be careful.