Starting from the high end and deciding to stay at the first working baudrate might result in 115200 baud. Without a FIFO, that means 10k receive interrupts/second. If you get a 100-byte block it a single burst, there will be very little time to service any other interrupts or run the main loop for 10ms. If you have a couple of other interrupts running at more than 100Hz, you run a very high risk of dropping serial data and/or other data.

Another thing to remember that you don't only get data based on the modem-modem transfer speed. You also have echo of your own commands, and if you ask the modem a question, the answer is generated within the modem.

Settling for a "fast enough" baudrate instead of the highest possible is important to reduce the maximum peak load.

For 3G modems (the ones who still has a traditional serial port and hashn't just an USB or SPI interface) it is important to support very high baudrates, or it wouldn't be possible to take advantages of the high network speeds allowed by the standard. In that case, we are talking about short distances and without any RS232 transceiver chips with explicitly limited rise times.

And GPRS and 3G modems may for example produce significant amounts of data if you ask about SMS inbox or retrieve an SMS or MMS. And some modems have a hard time handling handshake signals. Because of the high speeds involved, one modem I use will send up to 128 characters after I request it to stop - and in the other direction, the modem will accept at least 128 characters after it has signalled that it is full.

So in many situations, the baudrate may be the most important flow-control parameter available when mating a small processor with a modem of unknown capability. Andy hasn't said, but we can't assume that his modems are limited to connects speeds of 56kbit/s or lower.