> 1. низкий ртт и препуш нужен только дудлу и ещё паре рекламных сетей, так они смогут повысить показы рекламы, а то хомяк может свалить раньше, а то и вовсе у него в днс домены с рекламой заблочены а тут ему сервер сам всё что "надо" отправит раньше, чем будет обращение к днс.

Бред. В какой это галактике юзер уходит через 100-200мс после начала загрузки и не успевает увидеть рекламу?
С чего это пропадает возможность игнорить то, что отправил сервер через пуши, если он отправил говно? И серверный пуш уже есть в http/2 пару лет (а до этого был в spdy гугла), где ты видел абьюз для рекламы и невозможность заблочить?
И зачем вообще мучаться с целым новым протоколом, когда гуглу можно просто в хроме запретить сторонние блокировщики, внедрить свой и блокировать неправильную рекламу, оставляя правильную? Что он собственно и делает прямо сейчас, без всякого QUIC. Не надо путать тёплое с мягким.

> 2. контроль перегрузки - так тцп имеет историю огромную и там оно тоже достаточно вылизано, в том числе и дудлом.

Вылизан там костыль. Огромная история там костылей. За 30 лет так и не вылизали нормально проблемы.

> 4. а какой зоопарк будет в софте: ведь каждая софтинка которой нужен этот убогий протокол должна где то найти либу с ним или притащить с сбой

Ага, ведь лучше ждать когда в ядра, ОСи и железо поддержка придёт. Может увидим использование протокола через 20 лет. Или не увидим даже тогда, как вышло с SCTP.
Расклад таков, что либо ты со стороны софта внедряешь новый транспортный протокол, либо ты никак не внедряешь. Не говоря уже о том, что в интернете могут существовать только TCP, UDP и надстройки над UDP. Что-то иное вообще невозможно никак внедрить.

> 5. из за крипты повышенная нагрузка на проц даже там где крипта не впёрлась ни разу

Никого не волнует, что тебе где-то не нужно шифрование. Оно будет везде. И без QUIC, и с ним, не в нём дело. А в том, что шифровать только важное нельзя, ибо это будет палить важность данных. Шифровать надо всё, даже котиков, чтобы трафик котиков и чудовищных тайн выглядел одинаковым. Эта задача давно в процессе и почти выполнена без QUIC, а недовольные могут пройти в свой уголок интернета.

> 6. браузер по тцп может и рожает пачку соединений, и хотя это несколько дольше, но в итоге данные передаются быстрее, а сравнивать с одним соединением не корректно
> 3. попытка проскочить мимо шейперов, которые умеют тцп и не умеют квик

И почему же быстрее? Неужели твой tcp так обманывает шейперы, прямо как ты обвинял quic в 3 пункте? Ведь физический провод от одного узла до другого по сути один в некий момент времени, в случае tcp. Ответь мне, почему пачка tcp соединений по физическому проводу быстрее, чем одно tcp соединение по тому же проводу?