It's not dark magic, it's just that there is no hardware limit for 9600 bps to begin with.
There are many factors at play here, it's just not about the UART chip.
The speed depends on basically from these items:
- Design & marketing plans/specs of an IBM PC before hardware was designed
- CPU speed
- ISA bus speed between CPU and UART
- Disk transfer speed
- The UART chip itself
- How the UART chip is clocked
- The level translation circuit to convert between TTL and RS-232 voltage levels
- The RS-232-C standard itself
- IBM PC BIOS
- Operating system (DOS)
- Software (such as Laplink or Fastlynx)
- Null modem cable used
The Wikipedia page does not tell the whole truth - yes of course if you use interrupts, and there is the weird assumption of 1ms interrupt latency, it will of course result into a limit of 1000 bytes per second, which gets approximated to standard rate of 9600 bps. If you don't have such latency, or don't use interrupts to begin with, you can send at any rate the hardware is otherwise capable of. There is no explanation why would a system have this 1ms interrupt latency, as it makes no sense, at least in the case of the IBM PC. Any of those UARTs listed could most likely go past 9600 bps just fine.
And regarding the IBM PC specifically, it is likely that general specs were first fixed before actually it was designed. If the specs say that it must have serial connectivity up to 9600 bps, then that's the specs, even if designers later on chose an UART chip that is capable of faster speeds.
CPU speed and ISA bus speed are obviously not issues. Even the 4.77 MHz 8088 can talk via ISA bus to the UART chip at a rate of about 0.9 megabytes per second. Good enough for transferring at 115200 bps even.
The largest effect comes via disk transfer speed. Most likely data transfer between UART and disk are interleaved, as you don't want to miss UART data byte interrupts while handling disk interrupts. So there has got to be a small delay when accessing disk before full rate UART transmission can continue.
The UART chip that IBM first used was National INS8250N-B. It can work with up to 3.1 MHz baud generator clock, but there are limitations in the divided frequency. Divide by 1 must be below 1 MHz, divide by 2 must be below 2 MHz, and divide by 3 must be below 3 MHz. The datasheet gives example baud rate tables for two different clock values, 1.8432MHz and 3.072MHz. Since both are high enough, and slower clock is always easier to deal with, IBM chose the same 1.8432 MHz for their baud clock crystal. Either way, divisor of 1 will exceed the safe chip baud clock limits, so basically, 115200 bps should not be used. Divisor of 2 is safe to use regarding the divided clock limit and it gives 57600 bps. However, the datasheet mentions that baud rate should not exceed 56 Kbaud, which means first usable safe divisor is 3 equaling 38400 bps - far beyond intended use anyway.
Then, there are the RS-232 tranceivers which convert the signals between TTL level UART and RS-232 connector voltage levels. They are SN75150 transmitter and SN75154 receiver. Datasheet for SN75150 says that it can drive a fully RS-232 compliant load when used at up to 20 Kbps. So under worst case load, you are limited to 20 Kbps, while with lighter loads it is possible to go faster than 20 Kbps in theory.
But why the tranceivers are specified only up to 20 Kbps? It comes from the RS-232 standard - it defines an interface with electrical specifications up to 20 Kbps. So even if you used faster speeds, they would not be governed by the specs - if it works then it works, but it does not have to work, it's beyond the standard so it does not apply.
Since marketing specs only go up to 9600 bps, so does the BIOS support. And OS mainly used the BIOS, so even if later DOS versions could maybe go up to 19200 bps, the early DOS versions were limited to 9600 bps.
Any software running on the DOS system can do whatever it likes, whether or not the hardware actually supports it.
So, in light of this, everything in the hardware should be specified to work to 19200 bps in RS-232 standard compliant fashion. If the tranceivers and wiring allows, going above the specs to 38400 bps is not an issue either since the UART supports it. 57600 bps will violate the 8250 UART datasheet statement about max baud rate of 56 Kbps, but if it works it works. 115200 bps is kind of pushing it, as it violates the baud rate clock limit, in addition to the all previous limitations of the hardware, but given a right UART type or if it just happens to works, it works.
Sure, the later 8250A and clone chips might fare better than the original 8250.
But given the right hardware, there should be no problems configuring UART for 115200 baud settings, and transferring 11520 bytes per second. Which equates to 92160 actual payload data bits per second. So yes, 90 kbps sounds doable, even on a 4.77 MHz 8088. The 9600 bps baud rate is an arbitrary limit which does not exist in any way.
Some data transfer programs such as Laplink and Fastlynx also use the UART handshake wires for data transmission, which allows to transfer even faster than the selected baud rate allows. Typically, only DTR->DSR and RTS->CTS wiring is used for extra speed, and this is the so-called 7-wire null modem cable. The 3-wire null-modem cable only used the TXD and RXD with ground for the data transfer.
Turbo Mode, if memory serves, means larger data packets over the UART is transmitted to reduce the overhead of the headers. It also means the computer spends larger time periods doing nothing except transferring the data, so it won't respond to timer and other interrupts. This may cause incompatibilities and so this method does not always work on all computers or background TSRs.
The cables are recommended to be less than 15m (50ft) as per the standard, but longer cables are allowed as long as they don't exceed the cable capacitance limit of 2500pF, and that the capacitance is low enough so it does not slow down the signal rise/fall times beyond the limits (4% of bit length).