I should start by saying that I really like to work with Active Directory. And I freely admit that I'm somewhat rare, being more familiar with LDAP than your usual geek. But regardless, I think more people should be using ldp.exe.
If you've worked with Active Directory for very long, you know that the usual mmc snap-in tools leave a lot to be desired. The biggest problem with them is that they regularly hide information from you in the interest of "helping" you. And sometimes, in the interest of making stuff more fool-proof, they arbitrarily limit what you can do. In general, I hate most of the AD mmc snap-ins. I will use them occasionally, especially for doing ACL work, because the alternatives for doing ACL work are very, very ugly. So in my opinion, they are good for a few things, but in general, I use ldp.exe instead.
Ldp.exe takes a bit of getting used to, and is not for your general casual admin. If you only occasionally need to adminstrate AD, then ldp.exe might help you out of a rough patch, but it likely won't be something you'd generally use.
Ldp.exe takes a more LDAP centric approach to AD. You connect, you bind, you execute other LDAP operations. You have access to specify LDAP controls that modify what the basic LDAP operations do. You have the ability to specify which attributes are returned, and the ability to directly set a filter so you can view objects which are in many different containers at the same time (unlike ADUC).
One of my favorite things about ldp.exe is that it enables me to see what is happening beneath the surface. And if I can see what is happening beneath the surface, then I am better able to understand what mechanisms are involved in any given technology, and better able to troubleshoot problems. It removes the blinders that the other mmc snap-ins throw on.
Now ... that removal exposes a lot of info, some of which is not especially useful. But you'd be surprised at how much of the info that is typically hidden by say ADUC, is very useful. For example, pwdLastSet. I find it very useful to know when someone last set their password, especially if they are claiming that they just set their password and it doesn't work anymore. Does ADUC tell me this? And badPasswordTime tells me when the last unsuccessful password happened, which might help me in the above scenario to determine that the user is mistyping their username or the domain. Again, you won't see this info in ADUC.
As you become more aware of what is under the surface, you'll begin to find that there are ways to accomplish tasks that the mmc snap-ins won't allow. For example, if you want to configure an account for Kerberos delegation, specifying that it is permitted to delegate to a service on a computer that is outside your forest, you are left high & dry by ADUC. But by paying attention to what is under the surface, you see that the msDS-AllowedToDelegateTo attribute is where the trusted delegation information is stored. And so you can directly modify that attribute, adding the values needed.
But one of the most beautiful things about ldp.exe is the ability to find all the objects which meet some specific criteria. Say I want to find all the objects which have a uid set. Can I do that with ADUC? No, because uidNumber was not included in the advanced find functionality. But with ldp.exe I simply set a filter of (uidNumber=*), maybe specify that I only want the DN attribute (so I'm not deluged by too much info), and I see the list of all the objects with a uid. ADUC so rarely has what I want in its search options that I don't use that functionality of it at all.
Another one of the things I like about ldp.exe is that it allows me to find out the critical bits so I can write code which might do something useful. Granted, not everyone writes code, and certainly not many people write code against AD. But if you are, I can't imagine getting along without ldp.exe.
You can also use ldp.exe to connect to other LDAP directories which aren't AD. For example, you might want to connect to the UW whitepages directory. Or to the UW email forwarding directory. More related to this below ...
I should say a few things about some other tools.
Adsiedit.msc is nearly as useful as ldp.exe. It also gives you increased access to all the info. And it comes with the GUI ACL interface, which can be very useful, especially if you have a security problem in your configuration partition (rare, but it happens). And you can use it to enumerate all the *possible* attributes for a given object, which is a much harder task via any other tool. But it lacks the searching power, and configuration abilities that ldp.exe so I only call upon it occasionally. But I don't sneer at it the way I do at ADUC. :)
A short time ago, Mark Russinovich released an AD management tool called AD Explorer. It's interesting, in that it allows you to work with multiple domains, even across forests, at the same time. But I find that it has a sql-based approach, and this tends to limit it's functionality. I find that it is much slower that ldp.exe. It does simplify some things, but ultimately, I gave up on it.
I tried Softerra's LDAP Browser 2.6 awhile back. It also allows you to work with multiple domains or LDAP directories. It does have a LDAP based approach, but I didn't really like the way information was returned. My main desire in trying this tool was to see if it supported certificate-based authentication.
Which brings me to a final point. None of the tools I've mentioned provide certificate-based authentication. As you might know, both PDS and GDS require cert-based authentication. To my knowledge, there are no free Windows-based GUI tools that provide cert authN support.
As I've developed stuff which synchronized with PDS and GDS, this gap has driven me a bit crazy. For the longest time, I'd use visual studio, via the .net code I had developed to access PDS and GDS for troubleshooting and lookups. Then one day, I realized that I could make my own tool which addressed this gap. So I did. At this point, it isn't very fancy, and it certainly is not a GUI-based tool. What it is, is command-line based, and Windows platform based. I'd be happy to share this tool (or the code) with anyone who has need of something like this. The tool or code does not magically give you access to GDS or PDS, however. You will still need to request access via a certificate, and run the tool from a computer that has that cert installed (with access to the private key granted to the user running the tool).