Думаю, что разницу по скорости/ресурсам заметишь на более менее большой кодовой базе когда тестов будет > 500.

Имхо, чтобы юнит-тесты получалось легче и удобней писать, нужно код приложения писать особым образом. Бить логику на компоненты (logger, persistence-store, api-client) и стараться сделать их слабо-связными по отношению к друг другу (читать в сторону IoC). В результате перед каждым юнит-тестом можно подменить (замокать) реализацию того или иного сервиса:
- подменить Db на in-memory-store,
- не ходить по сети используя in-memory-api-client
- писать in-memory логи

Тут скорее от обратного — TDD приводит к написанию хорошего, легко расширяемого и поддерживаемого кода

К слову, стал замечать, что TS даёт возможность удобно установить контракт структуры сообщений сервер-клиент, проверяемый самой IDE ещё до запуска любых тестов. Ну и автокомплит родимый. Swagger все ещё нужен для описания урлов, статус кодов, заголовков. Но TS интерфейсы можно трансформировать в Swagger definitions (JSONSchema), и не дублировать работу.

GraphQL очень плохо ложится на реляционные БД. Если сзади него NoSQL и API нужно поддерживать разные виды клиентов, то штука удобная.