Speculation: each page had its own memory segment, and the page drawing (rendering) routine was designed to work with 16-bit NEAR pointers within the segment.
In the 16-bit world of Windows 2.x and 3.x, memory management informed the program architecture to a large degree. Each pointer could be NEAR or FAR (or HUGE), with tradeoffs in size, performance and flexibility.
I don't know about the internal architecture of Ami Pro, but it would have been possible/convenient to design the application to store each page in its own memory block/segment (probably allocated using GlobalAlloc). The Windows global heap could handle most of the large-scale memory management, including the ability to allocate Expanded or Extended memory blocks. The maximum size of a segment, 64 KiB, would have been quite enough for a typical page, possibly with graphics stored separately. The elements on the page could then be managed using NEAR pointers, possibly even using a local heap inside each segment.
The text display and editing routines could then be kept simple/fast because they could work with a single "active" page at a time, relying only on NEAR pointers. They would allow you to manipulate text within the page, with the complication that any text that flowed off the "bottom" of the page would have to be copied over to the memory block for the next page, etc. Showing two pages at the same time would have been possible but more complex.