Why should I restore System State rather than troubleshoot?
Some thoughts concerning why the quickest way to troubleshoot AD can be to simply restore the last good backup that you have:
Troublshooting any issue is always an unknown time factor. You simply don't know how long it will take, you could find the problem immediately or it could take several days. Compare this with restoring a backup which is a known time factor (assuming you know how long it takes to restore).
If you have a good backup of System State you're rolling your operating system back to a known state. Assuming that the backup doesn't contain the problem then you're up and running in the amount of time it takes to restore. This has the additional advantage of verifying your disaster recovery procedures - although this would optimally be something you'd want to have tested earlier.
Active Directory is designed to be distributed and fault-tolerant. As long as you have more than one DC in the domain and you're just making a normal non-authoritative restore you should replicate in to the restored DC any of the changes to users or AD settings that have been made since the last backup was taken.
In a perfect world, a Domain Controller should be just a DC and have no other roles. That makes it simple and convenient to restore it. In the real world however you'll frequently find yourself having to balance between several factors that may require you to assign additional roles to the DC, such as Exchange, SQL or other services.
The drawback of this is of course that this complicates any disaster recovery scenario. It also means you're attaching a service that is designed to be distributed and redundant (the AD DS) to another service which may depend on the server itself, effectively creating a dependency between the service and the DC you install it on.
Example: You install your Exchange 2003 server on a Windows Server 2003 DC, at some later point in the future there is a problem with the NTDS database on the DC which causes it to fail during startup.
Result: The Exchange server becomes unavailable to users even if there is another DC in the domain and the Exchange services themselves don't have a problem.
Finally; consider complimenting your normal backup routines by also scheduling a weekly backup of System state to file using NTBackup or Windows Backup, that way you have an extra backup to fall back on in case of a disaster recovery scenario.
As my grandfather used to say, "it's better to have a backup you don't need than to need a backup you don't have"