Windows Defender has advanced features for anti-exploit and more, it has mitigations that you can't get with another AV.
It's exploit mitigation capabilities are different to the approach
some other vendors take though.
Windows Defender Exploit Guard (WDEG) is designed to help make existing vulnerabilities for software become non-functional when deployed (and thus the exploitation attack is prevented), and prevent new vulnerabilities from being exploited if the exploit attack isn't prepared for the enforced policies.
Why is this?
It is because if an attacker is targeting a vulnerability using a hard-coded address (which Address Space Layout Randomization (ASLR) can break), or the assumption that they can gain code execute due to lack of Data Execution Prevention (DEP), then the exploit attack can fail unless it is flexible and has a work-around for ASLR/DEP/Any other mitigation's enforced by the person handling the configuration of WDEG.
However, some Anti-Virus vendors take the approach of not trying to replicate what EMET did in the past (which is quite similar to Windows Defender Exploit Guard now), and actually trying to mitigate actual vulnerabilities individually, instead of trying to make it harder to exploit existing ones or develop new ones for the future. Alternatively, they may take both the approach Microsoft did as well as a different approach.
For example, look at Malwarebytes Anti-Exploit. While it supports Bottom-Up ASLR and DEP enforcement, it also has a monitoring scope of trying to prevent heap-spray exploitation (and/or protecting against known Java exploits). It may prevent things that WDEG won't even be aware of, because WDEG works completely differently.
I do not believe Microsoft inject code into monitored processes by WDEG like they did with monitored processes by EMET and patch the memory of various API routines in NTDLL (for example). I think that WDEG is strictly process mitigation policies, and while it can be great if you know what you are doing and understand how you are using it for which software (since some applications are developed with a bad design which makes them break when features like ASLR or Control Flow Guard are utilized), it won't work identical to the other products which take alternate approaches and monitor behavior to mitigate known and zero-day vulnerabilities.
I could be wrong though, so please let me know if I am. So far this is my understanding of WDEG however it never really worked that well for me in my testing (unlike Malwarebytes Anti-Exploit which works superbly for me in my testing) so I am definitely open-minded on this.
Personally, if possible, I'd recommend using WDEG where applicable for policy enforcement as long as it is compatible with the software target, as well as an alternate anti-exploit component should it be compatible (e.g. if the enforced policies by WDEG does not break the other anti-exploit which is likely performing RCE) which takes a different approach (e.g. covers areas that WDEG does not and does not try to replicate what WDEG is doing).
As a final note though, I'd recommend avoiding any software packages which have been poorly designed in the first place. Sometimes you may make exceptions but features like ASLR and DEP alone are important so I'd watch out for the usage on those, I cannot stand applications which avoid using them intentionally. You can also look into whether the software is regularly targeted and commonly loved by malware authors, that can be a sign of whether to ditch and find an alternate or not as well... not to mention you can do research on vulnerability history and public disclosure/patch timing for the software/vendor you're considering of relying on for something.