Ещё раз спрошу про, Ваш опыт ? Слушать советы и утверждения от человека без опыта, такое себе занятие

Это не советы

"Вы поменяете понятия. Вот и все"

Эти понятия вводил не я

Мой опыт - покрывал приемочными тестами админку агрегатора платежей, юнит тестами свой код. О чем это вам может говорить?

И я лично знаю что аутентифицировать юзера на каждый тест весьма дорого

И интеграционные(приемочные, функциональные etc., терминология сильно размыта) тесты это плохой признак

Они могут кое-как следить что кусок легаси кода работает

Есть, как вы говорите, класс. У него есть метод, паблик, и куча privat методом. Не важно сколько. Это не говорит о том что надо из приват методов делать паблик. По факту паблик метоб это своеобразный интерфейс который и следует тестировать, модель как вы писали выше. Если этот метод подразумевает что пользователь залогинен и имеет какую либо сессию, то авторизаций и мок данные просто необходимы для этого модуля.

Заметим что это не интеграционные тесты и не приёмочные

Слышал, знаем что такое

Это значит что у вас плохо спроектирована система)

Если класс  который отвечает не за аутентификацию зачем-то ее проверяет

Если класс отвечает, условно, за добавление комментария к посту, проверять аутентифицирован/авторизован ли юзер - не его забота

Размыта. Но это не мешает вам грузить нас этой терминологией на собеседованиях)

Поэтому можно провести границу Unit | не-Unit

Первые хорошо, вторые плохо, хотя необходимы, но чем меньше тем лучше

Забавно в контексте тестов слышать "плохо", а если у меня запросы сложные, например я напрямую в базе строю сложный объект, при этом php код линеен, иными словами юнит покрыто все, но при косяке в приложении я не могу сразу сказать что бэк тут не причем

Я ведь написал что они необходимы

Взаимодействие с вендорами юнит тестами не особо покроешь