(Sorry if this is double post, I didn't get a confirm from the blog software)
We use this heavily in our "Automation Framework" and wrap it in a driver that allows us to easily create mappings and generate tests. Think Microsoft's Test Professional, but the editing of Automated Tests being much easier without the pain of re-recording everything. UI Automation was a huge boon for us, especially because its one of the few ways to programatically interact with Windows Presentation Foundation interfaces. This saved countless man hours of work, and in addition was included!
The only thing I'd include in Raymond's blog is the suggestion to use the "Inspect" tool included in the SDK which based on my understanding is what they intend you to use, its almost like a UI Spy, but specifically for UIAutomation (and MSAA to an extent). It does a really nice job of showing you the "Tree" it sees along with just about any other piece of information you'd most likely need for writing UIAutomation "Clients".
For all of its pros there are some cons, for one I couldn't for the life of me find a book on it, and at the time the MSDN documentation was a little scarce (but I've noticed that it has improved in recent years). We had some experience coming in dealing with automating programs which use the windows 'Common Controls' which was a big help. We also had access to the code which we were automating so were able to add AutomationId's to our projects which is a big help.
Third Party support seems a little spotty, but it is getting better (I won't mention names as per the blog rules) with some of the more well known control makers out there. All of the "stock" controls have great support already which is a testament to the team responsible for WPF. I do wish there was more documentation (I know wrong blog) on how to implement custom AutomationPeers, our product has a few places where we've had to create custom controls internally and it'd be nice to actually extend a custom AutomationPeer instead of the FrameworkAutomationPeer default (although I appreciate that its there, for 95% of what we do its good enough because it enables you to slap on the AutomationId and get a simple Click and BoundingRectangle).
The last thing I'd mention (and yes again I know not the right blog, I'd like to get in contact with the author(s) and buy him/her a case of beer) is that I'd like to see how you add AutomationId's to WinForms and MFC type applications. The MSDN Documentation seems to be very WPF-centric which makes sense as It seems the push for this was during the introduction of that technology. For those wondering, in a lot of cases when the Framework can't find a good AutomationId for these windowing libraries it falls back to using the Window Handle, which of course is not reliable.
As always great blog Raymond, sorry for the length of the comment, but I'm super passionate about this stuff and I LOVE when your blog mentions this type of stuff! Brightens my day right up.