Я, в РФ? Смеётесь, что ли?

Чего ради у всех будет валиться? Ничего не мешает реализовать любую алгоритмику,  включая ту, что есть в TCP. Но скорее будет нечно более подходящее - все получат неполные куски и будут пытаться что-то с этим делать (отправка нас интересует в десятую очередь - мобильные устройства - это о потреблении контента). И с шансами сможет сделать хоть что-то. Если не совсем тупа реализация - будут просить ретрансмит не на каждый пакет, использовать то, что получили и так далее. Да блин, даже просто возможность отдать веб-приложению сообщение "у нас потери пакетов, реагируй" дорогого стоит. В общем, я не спорю, что оно костыльно (как любой монолит, который на иерархию уровней клал), но ровно по тем же причинам и плюсы свои имеет.

В TCP  я не получу пакет пока не придут предшествующие ему, со всеми ретрансмитами. При мультиплексировании загрузки кучи ресурсов в одно соединение - не самая лучшая идея. При TCP  я не смогу использовать восстановление в видео, которое нынче по HTTP летит. А в кастомном протоколе - запросто.

Что до инженеров... фишка-то в именно в том, что TCP проектировался для одних условий, а используется совсем в других. Борьба с buffer bloat - это, конечно, часть попыток это дело поправить, но, как ни крути, один протокол на уровне операционки как-то хреновато подгоняется под конкретные задачи, и апдейтить реализации несподручно. А тут - новый хром прилетает с любой нужной частотой, и дело в шляпе.