В чем суть WinApi?
Windows API — это самый низкоуровневый интерфейс Windows, доступный прикладному программисту — в том плане, что он на долгосрочной поддержке и не изменится с Windows 11.
Поверх Windows API работают все BOOST и STL.
Пример: читать файл в 130 мегабайт по одному байту. Добавив асинхронного чтения через OVERLAPPED, я сумел это сделать менее чем за 2 секунды (это был поток общего назначения с виртуальными read(), write() и seek();  специализированный прикладной буфер даст ещё выигрыша, но и это хорошо). То же самое через FILE* — не дождался.
Пример второй, всё те же файлы. Дело в том, что Excel захватывает свои файлы на всё время, пока он открыт. Закрывать? — плохой выбор. Добавив один флажок в CreateFile, документы всё-таки стало возможным открывать при работающем Excel.
Вы не так понимаете значение "Win API", давайте расшифрую: "Windows Application Programming Interface" или "Интерфейс программирования приложений ОС семейства Windows". Т.е., во-первых - через этот интерфейс осуществляется взаимодействие любых программ в ОС с самой системой. А что такое ОС? Это прослойка между железом и прикладными программами, которая занимается управлением ресурсами (процессор, память, и т.п.). Давайте уберем Win API - что останется? А ничего вообще не останется - даже ОС (ну может там загрузчик ОС останется или что-то еще совсем низкоуровневое). Тогда, как же прикладная программа может быть запущена? Ну, так же как и все ОС: загрузиться с загрузчика, инициализировать процессор, видеокарту, аудиокарту, клавиатуру, мышку, какие-то дополнительные железки - чтобы все это использовать. Только вот чтобы все это железо использовать - к нему часто нужные драйвера. А некоторые из них проприетарные (т.е. исходников нет). И это только начало. А процессоры-то у нас многоядерные - а программа одна, значит надо реализовывать поддержку нескольких потоков, управление памятью. А если несколько программ хочется запустить? Тогда, надо как-то по очереди давать пользоваться процессором - для этого надо писать управление потоками и памятью, при этом для обеих программ должен быть реализован одинаковый интерфейс. Что-то вроде API. Хмм, кажется где-то было что-то похожее? Ну да ладно. Кстати, если подняться чуть выше в категории - можно обнаружить, что кроме Win API, существует еще Linux API, BSD API - да и вообще в любой ОС есть свой API. И они отличаются - поэтому нельзя напрямую запустить приложение от одной ОС в другой ОС, т.к. приложение банально не будет знать "языка" этой ОС и как дать понять ОС что от неё хочет приложение. Так что любая ОС - это просто менеджер ресурсов ЭВМ, можно сказать "фреймворк", а API - это "язык", на котором приложение может общаться с этим фреймворком. Всякие стандартные и не стандартные библиотеки и прочее - это еще один уровень абстрагирования от "низкуровневого" ОС API. Над библиотеками делается какой-то еще один уровень абстрагирования и его опять называют фреймворком, а там и еще сверху часто бывает что-то. Так что получается, что фреймворк сидит на фреймворке и фреймворком погоняет. Ну и при этом львиная часть ресурсов ПК уходит на все эти абстрактные слои между фреймворками. Поэтому даже в 2017 году, после 27 лет развития браузеры по-прежнему тормозят.