Но пахнет всё сильнее.

Ну, делай

Ну а что можешь рассказать про тс? Использовал сам?

В проде не использовал, на боевых проектах. Могу сказать, что это инструмент либо для публичных проектов, которым нужно обмазываться типизацией внешних апи, либо для больших команд/проектов. Чтобы формошлепать или небольшие спа на десяток экранов делать оно нахуй не нужно, больше сложностей доставит только.

Но я могу быть и не прав, дискасс

И моё мнение только в контексте фронтенда, в бэкендах/электронах не шарю - там может и без тса жизни нет вообще

Вопрос типизации не заключается в ошибках типов, как считают многие
Типизация принесла большую пользу инструментом, который появиля позднее - определение возможных вариантов свойств объекта на основе его типа, который позволяет посмотреть все свойства объекта, параметры методов, возвращаемых значений и прочей информации, необходимой для разработки, не выходя за пределы редактора кода.Что ускоряет процесс. Плюсом она не дает строить нежелательную архитектура типа: string | number, приводящую к неочевидным результатам, массивы с разными типами внутри и т д.
Конечно, теперь приходится писать название типа, что немного дольше, но теперь и нет проверок на тип входящих параметров методов и глупой архитектуры  метода с одним параметром, который может принимать и числа и функции и строки.
Я любые проекты пишу на ts, даже мелкие, вроде лишего времени не занимает, только на первых порах изучения, но это лишь порог входа, дальше все становится проще

Можно в tsconfig добавить "noImplicitAny": false, и юзать как проп-типы без типизации каждого чиха

Сами по себе ошибки типов не имеют ценности, тут соглашусь. Насчёт понимания кода, соглашусь, с оговоркой, что код должен быть хорошо и грамотно типизирован сложными типами/ интерфейсами, хорошо быть декомпозирован на сущности, т.е. в целом требует довольно более серьёзного подхода, нежели просто описания всех входных и выходных структур.
Насчёт подсказок в иде не соглашусь - они прекрасно сейчас выводят типы даже внутри нетипизированного кода

Это вообще несерьёзно. Примерно как купить вертолёт, чтобы ходить в магазин в 200м от дома

С TypeScript не работаю, но пару раз были случаи, когда с сервера приходит число в виде строки, а на фронте число. В результате компонент корректно не работает, сразу не понятно почему, приходится явно приводить к Number входящие числовые параметры

Т.е. где-то в компоненте происходит сравнение на ===, которое сравнивает числовую строку с сервера и число на фронте на JS

Тебе бы и в тс пришлось его явно приводить) Только вообще во всем коде, трахать я с тайпгардами и обкастами, ради мнимой безопасности)

Если все круто затипизировано, то код становится легче читать. Потому что ты понимаешь, что такое сущность А и что это гарантированно сущность А, а не Б, даже если она прошла сквозь 100 компонентов и функций. Вот только в этом плюс, но этому есть цена и на мелких проектах оно просто не прочувствуется.

Ну это если мы обращаемся к this, то подсказки работают хорошо. А вот если мы напишем функцию:
get(p) {
   p.
}

То что я получу в качестве подсказки после точки? А я на самом деле использую библиотечный тип для входного параметра и js его не сможет достать, потому что в node-modules очень много типов.
Я не утверждаю, что это крах, но я, работая на чистом js частенько ошибался в названиях свойств и методов и получал ошибки после сборки. Кстати, ошибки необъявленых переменных хорошо находит ESLint, без которого ситуация с js ещё хуже. Впрочем его я использую и на ts

Да, удобочитаемость на высоте, сразу понятно, с чем работает метод, согласен)

Вообще интересная ситуация - статически типизировнные языки, например, как C++ реализовывают автовывод типов (теперь можно писать auto x = ...)
А скриптовые языки приходят к явной типизации

Не молчим )

Неплохо неплохо