Вообще же гуглил по теме гомотопической теории типов и унивалентным основаниям математики как новому способу определения оснований математики (альтернативному теории множеств). Не нашел научпопа - наверно, его нет еще; также пока не видел осмысления философами.
Всюду обман.
На самом деле эта теория не станет научно-популярной, пока не появятся другие её приложения в информатике, помимо доказательств утверждений. Причём в более популярных языках программирования, чем Haskell.
А возможные приложения могут быть такие (примеры для C++, но годятся для любого языка, реализующего объектно-ориентированное программирование):
1) преобразование типов в C++. Пусть функция описана как func(тип1 x), а вызывается как f

с фактическим параметром y типа 'тип2'. Если теория позволяет преобразовать фактический параметр y к требуемому в описании функции типу 'тип1', тогда вызов f

можно считать корректным и выполнить.
2) полиморфизм функций в том же C++. Язык позволяет описывать применимые к классу методы (то есть функции, в которых всегда по умолчанию передаётся переменная данного класса) с одним и тем же именем, но с различным количеством и типами формальных параметров.
Классический пример такой функции есть даже без класса. Это форматный вывод printf. Он имеет 1 или более параметров. Первый параметр - это форматная строка, задающая формат, в котором будут выводиться на экран значения переменных, а второй и следующие параметры - сами эти переменные.
Например:
(1) printf("Привет") -- выводит строку "Привет"
(2) printf("x = %d", x) -- выводит строку "x = 3" (при условии, что целая переменная x имеет значение 3)
(3) printf("%s = %d", str, x) -- выводит строку "номер = 3" (при условии, что строковая переменная str имеет значение "номер", а целая переменная x имеет значение 3)
и т.д.
Традиционно полиморфизм в C++ реализован так. Когда вызывается метод func c фактическими параметрами x (типа 'тип1') и y (типа 'тип2'), то компилятор ищет в списке методов полностью соответствующий данному вызову метод. Причём соответствие проверяется так:
(1) должны совпадать названия методов (то есть название должно быть именно 'func')
(2) должно совпадать количество параметров (то есть должно быть именно два параметра)
(3) должны совпадать типы параметров (то есть первый параметр типа 'тип1', второй параметр типа 'тип2')
(4) должны совпадать дополнительные атрибуты методов (вызываемого и определенного в классе)
Таким образом, метод должен иметь вид: func( тип1 a, тип2 b ). [1]
Что можно тут получить от гомотопической теории типов? Ослабление требования [1] при поиске соответствующего вызову метода. Вызываем func(тип3 c, тип4 d, тип5 e); в списке методов такого нет, но при помощи стандартных преобразований (причём обратимых и без разрывов) можно привести такой метод к одному из методов в списке.
Пока в C++ такого нет, но вполне может появиться в будущих версиях. Так же, как появились лямбда-фунции из лямбда-исчисления или ключевое слово final, заимствованное из языка Java.
Вот когда появится, тогда это и будет интересно кому-то, кроме математиков, которые занимаются основаниями математики и теорией доказательств.
Что касается теории доказательств, то возникает ещё одно возможное приложение теории в информатике - расширение языка Prolog. Он используется в том числе и для доказательств утверждений придуманным мадам Робинсон методом резолюций. В этом методе требуется приведение логических утверждений к нормальному виду. Если данная теория позволит делать это автоматически, тогда мощность языка возрастёт значительно. Можно будет решать намного более сложные задачи искусственного интеллекта.
А в текущем состоянии, когда используются весьма экзотические языки и малоизвестные программы вроде Coq, теория навряд ли кого-то заинтересует.
Чтобы новая модель костюма стала модной, надо нарядить в неё знаменитого тенора.
Примеры я привёл такие, поскольку специализация у меня была "Алгоритмические языки" на соответствующей кафедре, и я написал несколько компиляторов (в том числе языка С для одного хитрого процессора). Возможно, что есть и другие приложения. Автоматическое преобразование вообще очень полезно, но с другой стороны опасно в применении, так как программа начнёт жить собственной жизнью и работать так, как программист и не подозревал. Для контроля должна быть возможность проверить это преобразование ручками по шагам.