Какие плюсы и минусы у асинхронного программирования?

А, слушай, про асинхронность! Ну это же, блядь, как машина с автоматом после механики — вроде удобно, а под капотом пиздец что творится, и если не понимать, как работает, то в кювет вылетишь на первом же повороте.

Плюсы, они же и соблазны, из-за которых все на это ведутся:

• Интерфейс не виснет, как твой комп на обновлениях Windows. Долгая операция пошла делать своё дело, а главный поток, отвечающий за кнопки и анимации, свободен. Пользователь тыкает куда хочет, а не смотрит на песочные часы. Красота, ёпта.
• Ресурсы не проёбываются почём зря. Представь, поток — это работяга. Раньше он стоял и пялился в стену, пока ждал ответа от базы данных или от какого-нибудь удалённого API через интернет. Теперь же он, пока ждёт, пошёл другую работу делать. Одним работягой можно нахуй больше сделать, вот и вся магия. Для серверов — это просто пиздец как важно, чтобы не плодить тысячи потоков, которые просто спят.
• Масштабируемость до овердохуища. Особенно для всяких веб-сервисов. Один сервер может держать тысячи одновременных подключений, не сдохнув при этом. Без асинхронности пришлось бы плодить поток на каждого юзера, а это дорого и тяжело.

Минусы, они же подводные ебли, на которые все наступают:

• Код превращается в спагетти, а отладка — в ад. Поток выполнения прыгает туда-сюда. Стек вызовов в дебаггере выглядит так, будто его составлял шизофреник. А если начнёшь мешать async с синхронным кодом через .Result или .Wait() — добро пожаловать в мир взаимных блокировок (deadlock), где всё висит и нихуя не происходит. Ищешь потом эту хуйню часами.
• Зараза расползается. Решил ты один метод сделать асинхронным — готовься переписывать всех, кто его вызывает, а потом тех, кто вызывает тех, кто вызывает. Это как цепная реакция, блядь. «Async all the way» — не просто красивая фраза, а суровая необходимость, иначе получишь пизды.
• Контекст синхронизации — вот эта хуйня, которую все забывают. В приложении с интерфейсом (WPF, WinForms) после await выполнение вернётся в тот же UI-поток. В ASP.NET Core — нихуя подобного, там своего контекста нет. И если этого не понимать, можно наделать дел. ConfigureAwait(false) — это не магическое заклинание, а осознанное решение «мне похуй, в каком потоке продолжать, главное — эффективно».
• Это не волшебная палочка для всех задач. Если у тебя тяжёлые вычисления (CPU-bound), то async/await сам по себе новых потоков не создаст. Ты просто асинхронно заблокируешь текущий поток. Для вычислений нужен Task.Run или что-то подобное, а это уже другая история.

Вот, смотри, как это выглядит в менее ебанутом виде:

public class DataService
{
    private readonly HttpClient _httpClient;

    public async Task<string> FetchDataFromApiAsync(string url)
    {
        // Тут поток говорит: "Окей, я пошёл запрос делать, вы меня разбудите, когда ответ будет".
        // И освобождается, чтобы чатики проверить или ещё что.
        HttpResponseMessage response = await _httpClient.GetAsync(url);
        response.EnsureSuccessStatusCode();

        // Тут тоже самое — чтение ответа может быть долгим, поток не держим.
        string data = await response.Content.ReadAsStringAsync();
        return data;
    }
}

// А используешь потом в контроллере или в форме:
// await dataService.FetchDataFromApiAsync("..."); // Интерфейс не зависнет, поток не умрёт.

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