Evidentemente aunque hayas leído algo de información al respecto, estás lejos de haber entendido el proceso.

- De entrada, no todos los ejecutables están en formato PE, se puede compilar a código nativo.

- Cuando compilas un programa, si el compilador detecta que se importa una librería pero que luego nunca se llama (queda desierta), en general (suele ser opcional), descartará esas referencias y por tanto en el ensamblado final no hay noción a ellas. Es decir no tiene que resolver direcciones de funciones que ni siquiera serán invocadas, porque aún declaradas, no aparecen llamadas para usarlas en el código.

- Cuando se compila un programa, las direcciones de variables, funciones etc... son relativas, es decir el programa comienza la dirección 0 para la primera instrucción del programa (a grosso modo), luego cuando el loader (cargador), actúa localiza  memoria libre en el equipo, supongamos que es: 0010346AB1, pués el loader tiene como misión hacer las direcciones locales absolutas añadiendo ese valor a todas las direcciones relativas en el programa. Y esto se hace sí o sí siempre excepto que el programa sea un '.com', lo hace el S.O. Además es algo muy rápido... a no ser que tengas un ejecutable de 500Mb.

- Si bien el cargador se encarga de las direcciones relativas, fue el linker, el que se encargó de las direcciones de las librerías externas, y es ahora el loader, quien de nuevo tiene que resolver esas direcciones relativas a absolutas... y en el caso de que una librería no esté cargada ya en memoria debe cargarla, para así poder tomar su dirección. Aún así, los objetos se cargan a medida que se usan, es decir en tiempo de ejcución todavía queda por resolver algunas direcciones, pués para ciertos objetos ni siquiera se conoce su naturaleza. Estos enlaces selen llamarse 'Late binding', y para ellos si hay impacto en tiempo (en relación comparativa a 'early binding'), pero sigue siendo inapreciable a efectos humanos...

- La cpu, no tiene que "resolver" todas las funciones, a no ser que con 'resolver' quieras decir formalizar sus direcciones, que entonces sí es así, pero si con 'resolver' te refieres a ejecutar, no.
Solo se invoca y ejecuta el código que está en ese preciso instante en la CPU (el programa yace en memoria), en realidad una única instrucción a la vez (salvo paralelismo)... Es decir en un instante dado, la CPU sólo atiende a un único proceso (dejamos aparte los cores que tenga), da igual que tu programa tenga 20 funciones o solo 2, que llame a chorrocientas funciones externas o a ninguna, solo 1 proceso se está ejecutando en la CPU a la vez, pero no todo es tan así... hay algo llamado pipeline (cascada), que no es más ni menos que una especie de túnel de ejecución de modo que cuando una instrucción se está ejecutando, otra se está preparando, etc... similar a un ssistema de montaje en serie de coches, por ejemplo... Así, la cascada tiene varios niveles, además hay sistemas de predicción (para eso sirve la caché de la CPU), cuando se equivoca o se cambia de proceso, se tiene que limpiar toda la cascada... (algo así como si en el sistema d emontaje de coches deciden cambiar el modelo del vehículo, o incluso algo tan nimio como la pintura) y guardar en la pila el estado actual de la CPU para ese proceso, hasta su próximo turno.... esto siempre supone un pequeño retraso.

- Si un programa tiene (pongamos) 300 referencias de direcciones de librerías que resolver,  el impacto de carga es nulo (no observable a nivel humano), un pestañeo y ya...

Donde si se observa un notable impacto, es en dos casos muy concretos y claros:
--- Cuando se procede con código interpretado. El código interpretado puede ser entre 10 y 100 veces más lento, depende del intérprete.
--- Cuando previo a la ejecución hay una compilación (una traducción del bytecode (código intermedio igual que PE, pero por ejemplo en NET es CIL)). En NET, el caso es más severo (que en COM), ya que el código al compilar (desde el IDE) lo hace en código CIL, y es en tiempo de ejecución cuando CLR lo compila a código nativo, optimizado para el procesador que calza el equipo... Es un pequeño sobrecoste de carga a cambio de una mayor optimización personalizada para la CPU presente en el equipo en cuestión (durante toda la ejecución del programa), luego... quién tiene motivos de queja por ello... con todo, puede forzarse para programas que asíduamente se usan en un equipo dado, se compilen a código nativo... de hecho hay un servicio en el equipo que se encarga de ello: Microsoft .NET Framework NGEN. Este caso también se da con los programas en JAVA

Los compiladores modernos siguen el esquema UNCOL de Tanenbaum, que aunque jamás llegó a término, si mostró el camino a seguir. Actualmente una especificación similar es el CLI (Common Language Infrastructure) de Mocosoft.
Desde diferentes lenguajes, se compila a un código intermedio (CIL para NET), y luego desde código intermedio al código nativo en la máquina destino, así basta un único ejecutable para diferentes máquinas. Y a su vez puede haber un ecosistema de lenguajes aprovechandose de las mismas características del compilador, por ejemplo en NET tienes Visual Basic, C#, F#, Q#,  el suspendido J#, incluso uno mismo podría escribir su propio lenguaje y compilador.


Por último, señalarte que no tiene nada que ver el tiempo de carga de un programa con el rendimiento durante la ejecución del programa o de una determinada funcionalidad del mismo o llamada externa.