После компиляции трансляция?

Никакого промежуточного байт-кода нет.
Имеется в виду "слоистая" структура программного обеспечения операционной системы. Приложение вызывает функции операционной системы - функции GDI, которые находятся в своих DLL, например, и которые уже обращаются к конкретному аппаратному обеспечению. Опять же, через еще один слой - драйверов.

Т.е., например, имеем стандартный оператор

fstream << "Hello, world";

Он внутри стандартной библиотеки обращается к функциям Windows, скорее всего к WriteFile. Соответствующий код этой функции в Kernel32.dll будет уже обращаться к конкретным драйверам - разобравшись, где и на каком носителе этот файл - к драйверам USB, диска или еще чего. Которые уже на аппаратном уровне будут выполнять запись.

Т.е. ваша программа не должна знать, как работать с тем или иным устройством - для этого есть иные слои программного обеспечения. И программа будет работать независимо от того, выполняется ли она на машине с SDD, обычным винтом или работает с сетевым файлом на другом конце света. В программе есть только обращение к функции в Kernel32.dll, и которого и близко нет в исходном тексте.

Так более-менее понятно?

В этой фразе

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

слово "транслирует" используется не в том смысле, как трансляция программ. Это означает, что делегирует конкретную работу по выполнению запроса драйверам физических устройств. То есть вводится промежуточный слой в виде Windows API, который является промежуточным интерфейсом между прикладной программой и физическими устройствами с их драйверами. Это позволяет прикладной программе не знать детали, что происходит на физическом уровне. Эти детали скрыты в Windows API, которое для приложений предоставляет общий интерфейс.