In general, log management systems are as good as the log data - sounds like the obvious, I know, but there are some weaknesses in log data that a change auditing system can detect better, and generally those systems have more information about how much has changed or previous values of things that were changed.
Active Directory/Windows is very good about logging changes to member accounts - users (computer/user accounts) and groups. Users added to groups, deleted from groups, new users, etc. When you get into things like OUs and Group Policy, windows logging starts to lack a little in fidelity. Additionally, a lot of Windows event logging is not great at telling you what something was, only what it's been changed to. Change auditing systems generally take a snapshot of what's current and monitor for changes in that, and can tell you what it "was" and what it "is now" after a change is made - similar to what NCM does for device configs. Tripwire additionally has file integrity monitoring capabilities, which Windows lacks in. Again, the change auditing can help detect that a file really was changed and how much, versus windows generating a lot of potential noise.
When it comes to Linux, auditd can fill in a lot of these blanks, but may also generate noise, and you may still have the "was" and "is now" issue, if that's important to know. It's good at telling you things are changing, but change auditing systems try to know more about what has changed.
Some change auditing/management is done on a schedule and some is done in real-time, where logging (at least in these two cases) is always real-time. In this way, having the log data is a good place to start to know that a change has happened immediately. Some config auditing/management systems actually use the event logs to know that changes are being made.
For maximum detail, you'd use both - use the event log/syslog data for real-time notifications and when that level of detail is enough, use the config auditing/management for detail, scheduled scans, and filling in the blanks of things that the event log/syslog just doesn't get.
Awesome, thanks for the reply! This is exactly the type of explanation I was looking for.