SwvСтарт сессии такой дорогой?По дефолту сессия хранится в файлах. А ещё нередко эти файлы валятся непосредственно в системную /tmp, где иной раз многие тысячи файлов создаются и размер файла каталога распух. Соответственно, требуется обращение к файловой системе и при стечении неблагоприятных условий оно может оказаться накладным.
При желании можно хранить сессии в базе данных, в мемкеше и т.п., для этого можно написать свои обработчики и зарегистрировать их, ссылка на мануал: https://www.php.net/manual/ru/function.session-set-save-handler.php

Если в скрипте можно обойтись без сессий, то лучше обойтись.

Swvда и вроде как раз соединений всего 10 при тесте, то получается 10 сессий?А вот сие отсюда не видно!
Для начала фрагмент из мануала: https://www.php.net/manual/ru/function.session-start.php Функция session_start() создает сессию, либо возобновляет существующую, основываясь на идентификаторе сессии, переданном через GET- или POST-запрос, либо переданный через cookie. Таким образом, если клиент не передает в запросе идентификатор сессии, то сессия будет всякий раз новая. Будет тысяча запросов в относительно короткий промежуток времени (минут 20, скажем) - стартанет тысяча сессий, в /tmp появится тысяча файлов изначально нулевого размера. По дефолту время жизни сессии 14400 секунд. За это время можно при желании наплодить многие тысячи сессий и радоваться тормозам ФС.
Если же идентификатор сессии передан и запрашиваемая сессия на сервере ещё жива - тогда она будет продолжена. Для этого PHP должен будет открыть и прочитать файл сессии.

Можно наступить ещё на одни грабли с хорошими искрами из глаз.
Допустим, от клиента приходит некоторый Запрос-1 с идентификатором сессии, а следом через небольшой промежуток времени приходит Запрос-2, Запрос-3 и т.д. с тем же самым идентификатором сессии . Что будет происходить на сервере при таком раскладе?

Запрос-1 запускает некоторый скрипт, где в начале стартует сессия, затем скрипт что-то делает, делает, делает, закрывает сессию и завершается. Если не закроет - ничего страшного, при завершении скрипта сессия закрывается автоматически.
Запрос-2 запускает, неважно, тот же самый скрипт или другой, где в начале стартует сессия, затем скрипт что-то делает, делает, делает...
И так далее.

Так вот, фишка в том, что пока сессия, инициированная в Запрос-1 не будет закрыта, то скрипт, запущенный от Запрос-2 будет "висеть" на session_start() в ожидании, пока сессия не освободится закрытием или завершением скрипта от первого запроса. И если скрипт, инициировавший сессию, не закрыл ее максимально быстро, а продолжает неспешно что-то делать... В общем, в этом месте жестко формируется очередь, которую можно принять за тормоза.

Swvсетевое взаимодействие с базой съедает почти половину производительности?Только если говорить о поизводительности системы в целом. А так, конечно, сеть требует для передачи гораздо более заметный кусок времени, нежели локальное подключение через сокет.
Сам наблюдал примерно такую картину по производительности на одном и том же простейшем запросе вроде "SELECT 1;".
Подключение к БД через unix-сокет -17000 запросов/сек
На том же компе, но через TCP - 14000. Ну вот за пределы компа пакеты не уходят, а TCP-стек на себя уже сколько-то оттягивает.
При коннекте на другой комп, конечно, ещё более заметно, менее 10000.

Swvна домашнем компе стоит SSD. по идее сессии должны побыстрей создаваться. в плане файлов.Давайте не забывать, что файловая система работает не только напрямую с диском, но ещё и с буфером, находящимся в оперативной памяти. Сброс буфера на диск происходит обычно в фоновом режиме. На чтении с диска будет задержка в том случае, когда данные необходимого фрагмента отсутствуют в буфере. При относительно небольших объемах данных и частых обращениях, когда буфер ФС не вымывается из ОЗУ, различия могут быть вообще никак не заметны. При редких обращениях и интенсивном заполнении буфера какими-то другими данными оно уже будет заметно. В этом смысле кроме SSD есть ещё множество факторов.

Swvсеть съедает процентов 20 времени откликаДа ну? Давайте профилировать, давайте смотреть внимательно, что представляют собой эти 20% в исчислении времени и на что конкретно эти проценты расходуются в конкретном Вашем случае. Каждый процент.

Установление сетевого соединения, авторизация - процесс довольно долгий. Но соединение в ряде случаев можно и повторно использовать. Например, соединение с СУБД. Можно и вовсе держать пул заранее подготовленных соединений.