Here's a high level view of how the layout is loaded
Magento loads and merges all the layout XML files from the file system into one giant XML tree. This tree is cached if caching is on. This tree is called the "package layout"
Magento then looks through the list of "handles" issued for a particular request, and picks out the bits of XML from the package layout that match these handles. These results are merged into a single XML tree called the page layout
Then, Magento processes the page layout, instantiating a block object for each <block/> found, calling action methods, etc.
Then, Magento calls the toHtml method on the root block. If the root block's template contains getChildHtml method calls, Magento loads the block named in getChildHtml and calls its toHtml method. This continues all the way down.
The results of the above step are a string, which Magento sets as the body of the response object
One of the last actions of the Magento system code is to output the body of the response object back to the browser (or other output context).
So in your example, removing the call to getChildHtml means the block's toHtml method is never called, so you save yourself that processing. However, the block itself is still instantiated, meaning you do not save yourself that processing. The rendering of all those blocks is a significant reason for Magento's infamous performance profile, and why there are so many output caching strategies.
If you're interested in the full details of the rendering I described, my book No Frills Magento Layout covers the entire thing in simple, easy to follow chapters that build on one another.
