Если убрать футуры, то наши функции потеряют ссылочную прозрачность, и как следствие - более простой рефакторинг/чтение кода. Давай проверим: если мы заменим print_something() только на возвращаемое значение (которое будет () без футур), то поведение программы изменится.

и что ты тут рефакторить хотел?

Эмм, код?

https://habr.com/en/post/479238/

В секции "Зачем это нужно" есть показательный пример как ссылочная прозрачность понижает количество ошибок при рефакторинге.

ну вот какую часть кода? вот у тебя возвращается (), очень полезно, конечно, ведь он не синглтон ни разу. Тоесть у тебя и так всегда возвращается олно и то же значение, а значит функция пригодна только для сайд-еффекта. Внимание вопрос: зачем заворачивать её в футуру при этом, если можно просто взять функцию, которая желает то, что у тебя в async и заворачивать при желании? как это упростит рефакторинг? вот я сделаю extract method что с ней, что без неё, только с ней мне опять футуру таскать

у меня ни разу не было, чтоб именно при рефакторинге я что-то сломал.

Это MRE, слишком простой пример, чтобы его как-то пытаться рефакторить.

вот буквально, я не помню такого, чтоб я рефакторил, а не переписывал и сломал что-то

У меня было и много раз

только без R, потому, что он не репродьюсит ничего, просто "ну, вот так можно писать футуры"

попробуй языки, для которых работает автоматизированный рефакторинг

где IDE понимает код, а не ты как раб бегаешь и ищешь, где у тебя  foo -- переменная, вызов метода, декларация метода, строка или комментарий, чтоб sed'ом не сломать всё

где ты нажимаешь один шорткат и видишь как данные проходят через твою программу

Отсюда приходим к пункту "чтение" кода, или правильнее будет выразиться "понимание". С ссылочной прозрачностью ты можешь просто подставить вместо выражения его значение, в нечистом коде тебе придётся следить за неявным изменяемым состоянием.

не придётся, мне плевать, что делает метод который я вызываю,  он лучше знает, что ему делать

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

separation of concerns, простой принцип, который в фп-школе не проходят и пишут в одном месте вычисления, эффекты и всё-всё, как я понял

это если ты пишешь на коленке для олимпиады, то да

Этот принцип работает во всех парадигмах, в том числе - в ФП