The XBee ‘AT mode’ is made to look like a traditional smart modem's way of operation: after connection, you transmit/receive data one byte at a time. To control the modem, you use an out-of-band method, where you escape transmit/receive mode (often using the standard <pause>+++<pause> sequence), send commands, and optionally re-enter transmit/receive mode.
In API mode, commands and data travel to the X-Bee in-band packet by packet (not byte by byte). Your microcontroller is responsible for formatting each packet of command/data, providing the correct values for payload lengths, checksums etc (I don't recall the specifics at the moment, it's been a while). It's more work, but as Tim mentioned, it allows you to do much more with the X-Bee.
What the manual means in this context is that even though you're in Hayes-emulating mode, there are cases where you may get a burst of bytes that are actually an API mode packet. In essence, if this happens (and if you need this data), you'll need to include the code to decode these packets. This is what got me using API mode in the first place: it looks more complex, but is actually simpler, especially if you're doing broadcasts (in the networking sense) etc.