Имхо статья славы «ускоряем жметер» - вполне научный подход

На скалу надвигается проблема. Проблемища, я бы сказал. Называется Dotty/Scala3. Будет много потерь :)

Ну как сказать. Труд хороший, да. Но фундаментальные проблемы производительности не исследованы (а они там есть, судя по всему). Частные ошибки исправили, но только частные. Да и то, можно и их быстрее сделать :)

Научный подход в том плане, что делается предположение, делается проверка предположения, делается обоснование результатов

Так-то про любой результат можно сказать «можно и поглубже копнуть»

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

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

Я как-то заморачивался с оценкой степени корреляции кол-ва запросов с утилизацией цпу на тестах масштабирования.

Основная цель была рассчитать какое соотношение нужно между серверами nginx и backend, чтобы хватало, но и лишние сервера не держать.

Выбиралась модель, вычислялся критерий Пирсона на случайное отклонение, перепроверялось.

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

Пару раз приходилось использовать закон Амдала для определения максимального ускорения при параллельной обработке.

Вот, пожалуй, и весь матан в проф. области.

От монолитных БДешек в микросервисную архитектуру еще уйти, и горизонт проблем, которые нельзя решить горизонтальным масштабированием еще отодвинется.

в рамках непосредственно тестирования производительности почти негде это применить, да можно модели юзеров строить и распределения, имитировать аномалии, да можно модно считать результаты чуть сложнее чем апдексы и медианы, да можно пытаться коррелировать прод с перфом на основе моделей, применять законы литтла (даже интегрировать его для канкерси внутри системы) или делать идеальные данные для тестов. но, имхо, настоящий сайн или рокет сайнс начинается либо на стыке прод задач (больше SRE) или технологий и их применения

Ну а что для тебя сложное тогда? Вопрос чисто из любопытства.

Обычно «научный подход» применяется, когда нужно решить какую то проблему

Если просто научный подход ради научного подхода то это лишнее)

Теорию вероятностей удобно применять. При построении профиля нагрузки.

Пусть известно, что на продуктиве зафкисировано

10 000 логинов
10 000 открытый главной страницы
9 000 открытия формы создания документа
8 000 нажатий кнопки сохранить
7 000 нажатий кнопки подписать

Что надо сделать, чтобы получить профиль с таким распределением в JMeter/Gatling?
Чтобы нагрузка по логинам росла от 0,1 до 100 операций в сек, а все прочие операции были в нужных пропорциях

Чтобы применить критерий Пирсона нужно знать характер распределения. Или делать кучу предложений о разных распределениях входящий выборки. Почему то почти везде ошибочно предполагается, что распределения нормальное, и просто берется это как факт. Хотя оно почти никогда не нормальное, в лучшем случае сильно смещено, а чаще мультимодальное.
И вот все эти стандартные отклонения и математические ожидания, которые в статистике по тесту выводятся, они просто бесполезны, т.к. считаются по неверному посылу.

Так что начинать надо не с того, что его нет, а с того - какие проблемы вы хотите решить и чем в этом поможет научный подход