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

поэтому правильно использовать всегда async, кроме тех случаев, когда точно функция не асинхронная и не использует абстракции, которые могут стать асинхронными в будущем.

https://docs.microsoft.com/ru-ru/archive/msdn-magazine/2011/october/asynchronous-programming-async-performance-understanding-the-costs-of-async-and-await

https://devblogs.microsoft.com/premier-developer/the-performance-characteristics-of-async-methods/

https://markheath.net/post/async-antipatterns

Ничего не понял, можете пояснить?

а в чём проблема-то? практически любая бизнес-логика так или иначе работает с данными. это либо обращения к БД, либо к внешним АПИ.
подавляющая масса разработки в .net, это именно бизнес-приложения, -- это хлеб разработчика.
для программиста важно больше сосредоточиться на решении конкретных задач, для чего активно применяются паттерны и бест прэктикс.
судя по вашим очень абстрактным советам, программер должен крепко начать ипать мозги себе и коллегам на предмет "а это точно асинхронный метод или нет"? и городить интерфейсы сервисов, у которых часть методов асинк, а часть нет.
и заставлять всех париться на тему, а чё за херня происходит тут.
ну и в конце концов, подобный подход приводит либо к тому, что программист становится не эффективен, либо к болезненному рефакторингу за очередным умником, который привык вылизывать каждый гвоздик перед тем, как ударит молотком.
Microsoft советует следовать парадигме async-first, что означает по сути следующее: делать синхронными методы, в которых вы точно на 100% уверены, что они будут синхронными. остальные делать асинхронными.

и всё.