1) Он почему-то рассматривает только одно направление - upload
2) P2P-клиенты - не единственные программы, использующие несколько соединений, браузеры можно отметить тоже, скажем.
3) Тот же упомянутый BitTorrent писали не дураки - он хоть и держит много открытых соединений, но выбирает из всего swarm'а наиболее быстрые 3-4 коннекта, их и использует одновременно, не более.
4) Congestion Control опять же при реальном заторе приведет к дропу пакетов из разных соединений, так что опять-таки все коннекты станут медленнее в конечном счете.
5) Менять TCP-стэки по всему миру? Кошмар, автор в башне из слоновой кости живет, видимо. Тут бы уже давно придуманные ECN (могущий решить проблему тоже, кстати) у всех целиком внедрить...
6) Самое главное: контроль недаром введен в рамках одного соединения - они могут быть на совершенно разные направления в интернете, со своими характеристиками. Предлагает схему для гашения скоркости у всех сразу. Теперь представим, что с машины идут через ближайший роутер пара коннектов в интернет и один - в соседнюю сеть, не через внешний канал роутера. В каком бы ни был дроп, при предложенной схеме машина уменьшит скорость по ВСЕМ соединениям - то есть пострадают и те соединения, которые могли бы работать быстрее. И это естественно - откуда клиентской машине знать о состоянии каналов? Это задача для роутеров.

В общем, ему там в комментах аргументы приводили, да всё без толку. В том числе и то, что задача сейчас прекрасно решается равномерным шейпингом канала по числу активно пользующих клиентов в текущий момент времени. И это - реальный путь, в отличие от клиентов, которые, к примеру, могут себе и не проапгрейдить стек, а использовать злонамеренно (что опять потребует мер со стороны провайдера).