> Будет затык ещё на контекст свиче, а дальше что?

Дальше может быть переполнение приёмного буфера и потеря пакета. Когда-то случится ретрансмит. В случае TCP может быть неконтролируемый "затык" на время около нескольких секунд (до 5, а иногда и до 30 секунд). Уменьшить его можно, но обычно общесистемно (где-то в недрах sysctl в случае linux) и много где это сделает хуже (при работе с какими-нибудь медленными каналами типа gprs).

В принципе, если будет какой-нибудь ioctl/fcntl для повторной попытки отправки/настройки таймаутов tcp и прочего - многих это устроит.

В случае udp пакет можно передать в любое время. В tcp - следующий пакет не передастся до тех пор, пока не "пропихнётся" предыдущий пакет. А когда "пропихнётся" предыдущий потерянный пакет - решает TCP-стек/операционка. В udp будет "пропихиваться" когда отправляешь (конечно может и вообще всё udp потерять, но на практике теряется небольшой процент). Для задач типа передачи звука в реальном времени udp выходит лучше. Если бы tcp позволял как-то из userspace контролировать попытки повторной отправки - он бы тоже подошёл и для передачи звука в real-time.

Гугол решил, что и для ютюбчика вариант с udp лучше (потому как ждать по 30 секунд раскукоживания tcp - ну это жесть в современном мире). Вообще затыки на ютюбе стали как-то шустрее проходить, возможно, что и из-за http2/quic/spdy. А возможно и из-за чего-то ещё...