An alternative to using the built in NameMapping and Aliases feature is to use
FindChild,
FindAllChildren, and similar methods. So, you have an application and you want to find a particular box using a set of properties, you can do something like this.
var MyApp = Sys.Process("MyApp")
EditBox = MyApp.FindChild(["Property1Name", "Property2Name", "Property3Name"], ["Property1Value", "Property2Value", "Property3Value"], 30)
The above code will find the particular child object desired based upon the mapped array of properties and their corresponding array of values, searching down to a depth of 30 child objects.
IMO, this is a bit more cumbersome as you need to write this kind of code all over to manually find the components where as the NameMapping tool, essentially, does this already for you. The true beauty of NameMapping is in the Aliasing... as Alexei said, spend some time up front mapping those objects, components, etc, that you know you'll be interacting with and then adjust the Aliasing to "flatten" out the hierarchy to something more maneagable.
Also, IMO, recording is not the best way to populate the NameMapping because you have little control over it. Even after you record, you will still need to go back and adjust what properties are being used for the mapping, what names are being assigned to the component (so it has a name like "StartDate" instead of panelcalendarstartDate51231), and how deep the hierarchy is. I don't think recording is any time saving in this case but actually adds time. It's much more efficient, IMO, to do all the mapping up front and then do the recording... or, for that matter, I rarely bother with recording anymore except to give me a general "What is the order of the steps in this task" and I usually hand write library code to do what I need it to do.