Richard has interesting considerations in his blog about AD provider potentially being too dangerous as its use might be error-prone, so someone could type del * without understanding the current context and thus the consequences.
When we started working on our AD cmdlets we surely had a lot of discussions of the approach to take: cmdlets or provider. Frankly, we didn’t think of this danger of inadvertent AD changes that Richard mentions. We picked cmdlets as a way to give administrators more intuitive and functional commands to accomplish their tasks.
You see if you want add an account to a group it is probably more natural for you to type something like: add-groupmember than to use file-system metaphor for this not file-system-related task. Cmdlets also make the functionality more discoverable with tab-completion letting you easily see what parameters are available for that particular command on that particular object.
Does this mean that cmdlets are always a better choice though?
I am not sure really. I still think that being able to use the provider to browse AD, cd into OUs, dir their contents, etc. – is very impressive and in fact highly intuitive.
I guess bottom-line is that it is great that both projects exist and both are available as free downloads.
In his DEC session by the way Richard demoed how you can use those together piping out provider output into AD cmdlets. That was pretty cool. Richard promised to publish his demo transcript in his blog later on – if you could not attend his DEC session make sure you grab the transcript once it gets published.