Почему Dispatchers.Main использует один поток в Coroutines

А, ну это же классика, ёпта! Смотри, тут про Dispatchers.Main речь, штука архиважная. Если коротко — это твой пропуск в царство UI, где можно тыкать в виджеты, не боясь, что приложение накроется медным тазом.

Вот смотри на этот кусок кода, тут всё правильно:

lifecycleScope.launch(Dispatchers.Main) {
    textView.text = "Updated" // Безопасное изменение UI
}

Видишь? Запускаем корутину на главном диспетчере и спокойно, как в рот мне чих-пых, меняем текст. Без этого, если попробуешь из фонового потока ткнуть в textView, система тебе такого пиздеца устроит — CalledFromWrongThreadException вылетит, и всё, привет. А тут — красота, всё легально.

Теперь по пунктам, что он из себя представляет, этот диспетчер:

1. Гарантирует выполнение в UI потоке. Это его главная фишка. Он как верный официант — принимает твою задачу и несёт её прямиком в главный поток, больше никуда. Хуй с горы не свалится, всё чётко.
2. Позволяет избежать CalledFromWrongThreadException. Собственно, ради этого всё и затеяно. Чтобы не было этих идиотских крашей, когда ты с фоновой задачи лезешь рисовать кнопки. Доверия к таким операциям из другого потока — ноль ебать, система сразу вставляет тебе вилкой в глаз.
3. Под капотом использует Handler или Choreographer. Вот тут, бля, интересно. Это не какая-то магия, а старые, добрые механизмы. По сути, твою лямбду кидают в очередь сообщений главного потока, и он её выполнит, когда до неё дойдёт очередь. Всё гениальное — просто, ебать копать.

И главное, чувак, не путай! Не вздумай на Dispatchers.Main сетевой запрос или в базу тяжелую лезть. Для этого есть другие ребята — Dispatchers.IO (для ввода-вывода, файлы, сеть) или Dispatchers.Default (для сложных вычислений). А Main — священная корова, только для UI. Используй не по назначению — получишь фризы, и пользователи тебе такого пиздюля мысленно отвесят, мама не горюй.