Justin's comments in regular font, PM's in italics.
The reason for UI's having such a heavy dependency on asynchronous calls is that a lot of them are based on web services. The core data you access is rarely on the client's machines when you are creating more enterprise centric applications. Given that these services are inherently much slower than their desktop counter parts the processing can at times take over a second or two. Funny how that's considered slow huh :D? Breaking out tasks to be completed asynchronously, frees us to still be responsive to the end user even if that means just showing them a loading message. A loading message is an order of magnitude better than a frozen screen.
Let me see if I have the grand/parents thing right - please correct me if I'm wrong. Let's say we build an FBP loop. Look at the following diagram.
This is pretty close to what I have in mind, although this has more components than we need. In that case, the "back-ends" are remote sites where stock trades occur, but in your example, let's make them databases containing ancestry information. Let's say, for the sake of argument that the database containing my mother's ancestry is nearby, and that containing my father's is on Mars, say. ;-)
Let us have a general asynchronous function to get records describing the parents of individual 'x' from a remote database. Then we keep going round the loop with whatever we have retrieved, which will act like a bill of materials explosion. Each parent requests info about his or her parents, each of which in turn requests info about their two parents, and so on... If the records are perfect, the number in the loop doubles each time around, so there has to be room to hold them - probably a file id there isn't room in the RAM. But eventually the looping will start to damp out, once you get far enough back, and maybe stop, or you just cut it off arbitrarily. The Martian records will be lagging further and further behind the Terran ones, but that's OK, because, at some point in the future, you will probably want to sort all the results into some human-readable sequence...
Note that in the above diagram in a number of places two or more paths merge into one input port of a component - in FBP this means "first come, first served", so this is what lets things get around in the lowest possible elapsed time.
I also describe something similar near the end of http://www.jpaulmorrison.com/fbp/loop.htm - do a find on "Bill of Materials".