XSL-FO result tree structure design

Greetings,
I'm troubleshooting some timeout and memory errors in Arbortext 6.0
M010 publishing engine. The timeout errors, through a lot of testing,
appear to be related to volume of content. Specifically, I have a list
with numerous child lists that causes it to be long.

I don't think the issue is actually with Arbortext, however, and
taking a step back and looking at the structure of the XSLFO ouput has
made me wonder about the design that we are using. The way I have
experienced it, there are two possible ways of looking at XSLFO
output.

First, the way the stylesheets (FO 1.1) for my customer were designed,
is the "Russian doll" approach. In this approach, a given chapter of
content is the outer-most container. Sections are the next smallest
container, followed by subsections, etc. So, we start with an XML
structure:

Example 1: The Russian Doll
<chapter>
    <sect1>
      <sect2>
          <para>A lonely para in a cruel sect2.</para>
      </sect2>
   </sect1>
</chapter>

The transformed FO output reflects containers within containers within
the body flow (I use the id for reading ease, not in actual output):
<block id="chapter">
      <block id="sect1">
         <block id="sect2">
             <block id="para">A lonely para in a cruel sect2.</block>
         </block>
     </block>
</block>

This looks simple enough until I add in a ton of content. By the time
the chapter is actually being processed on live data, the largest
chapter block is vast, and I am beginning to think that this may be
why I am having memory and crashing problems.

The second way is to create loose blocks, outside of other containing
blocks, where possible.
Example 2: Loose Blocks (I don't mean blocks that are immoral) - result FO:

<block id="chapter"/>
<block id="sect1"/>
<block id="sect2"/>
<block id="para">A lonely para in a cruel sect2.</block>

Moving to this approach would require redesigning the stylesheets to
recognize key elements, I think - I haven't thought down this road too
far yet, and it may be moot to do so.

Finally, my questions, based on the above, and my limited knowledge on
how the Arbortext PE (and FO processors) work:
1) Is there a preferred method in result tree design that FO
processors prefer, especially related to memory allocation or
chunking?
2) Are there specific risks or benefits to using one of these two methods?
3) Are there other methods I am missing? Hybrid, etc.

Kind regards,
Michael Friedman