The relative importance of the serial comm timebase depends on where the async communication fits in the greater scheme of things. Apparently, it's first and foremost in your designs, hence does, as it should, receive prime consideration.

If you have a task, however, that requires that you do something, update the output on a port, for example, at a very precise time, when you do it, then you might be tempted to share a timebase between the time-critical task, and other tasks within your system. If you have to stay in synchronization, say, with a flywheel on a machine, you have a number of choices, one of which is to resynchronize each time you interact with that time-critical process, and the other, of course, is to use a timebase which will keep you in synchronization once you acquire it. This means, of course, that you must use the same oscillator, not two similar ones. Then, since you have frequency lock, you just need to acquire phase. I've had to do that many times, and selecting a crystal frequency suitable to both or all the processes that may require critical timing is second nature to me. Perhaps you've just never encountered a situation like that. It's certainly possible.

About the spelling ... English is my second language as well, though I've been using it since the early '50's. That's why I'm so pedantic about repeated errors. I used to nag my parents about their errors, and they got pretty good at English after a few decades, though there were some pretty bad habits my father kept. I don't nag about the typos, since we all make them from time to time.

RE