I think you're overstating the case, here, Erik. Lots of code is dependent on precise timing. While the UART may not work properly if you don't profide the correct oscillator frequency, some tasks may not work correctly if you don't do the same thing.

One reason for the development of microprocesors in general was as a logic replacement. The early MPU's didn't have internal timing or serial comm hardware. Many of the early app's used precisely that critically timed software of which the software-UART is a simple example. Apple, for example, produced a partly-hardware, partly software FDC. This saved them over $100 per system in the early days of FDD's, combined with the changes they made to their drives.

Writing precisely timed code often is complicated by using a specific crystal frequency because it's not convenient to use a different one due to internal hardware constructs like UART's. I don't know how you have to resolve timer vs UART requirement conflicts on an 805x series MCU. Some MCU's allow external baud clocks, and/or external timer clocks. That might help. I seem to be handlind those things on a case-by-case basis, even after all these years.

However, no amount of argument will make the need for precisely timed code segments go away. If you have to interface, via bit-banging, a serial stream, from a tape drive, for example, at 48 KHz, while using an 11.0592 MHz clock, you may have to struggle just a bit. You can do it though, but it will require some head scratching and maybe even some carefully written straight-lined code in order to stay within tolerable limits.

RE