Depende muy mucho del compilador, y sobre todo, del micro.
Mi experiencia programando tanto en ensamblador como en C los AVR y los Cypress PSoC me dice que esa es una noción incorrecta, especialmente para los micros 'C friendly' como los AVR/ARM/MIPS.
Tuve que optimizar alguna pequeña subrutina de algún programa escrito en C, compilado con IAR para obtener el máximo de velocidad, y apenas pude mejorar nada. Claro que saber cómo escribri el código en C para que salga más optimizado también ayuda. Como ejemplo, para los AVR y ARM, los bucles descendentes que terminan cuando el contador vale 0 se optimizan mejor y necesitan menos ciclos para ejecutarse.
Por otro lado, el C es como una gruesa alfombra bajo la cual muchos fabricantes esconden las miserias (y las virtudes) de muchos micros. Por eso considero interesante, obligado en mi opinión, el aprender ensamblador. Y por ello, te recomiendo que eches una mirada a los AVR (que son de 8 bits, más sencillos que los impresionantes ARM de 32), y verás la diferencia entre arquitecturas obsoletas como la del PIC (de los 70) y las más avanzadas (de los 90) de los micros multi acumulador (múltiples registros W).
Hace ya algún tiempo lancé un guanto a los programadores de PICs que trabajan en ensamblador, donde yo hice un sencillo programa en C para AVR, lo compilé con el GNUGCC - WinAVR (gratuito y no tan bueno como el IAR). El reto era hacer lo mismo en ensamblador, lo más optimizado posible, para los PIC, y comparar el resultado de la compilación, que queda en ensamblador, entre ambos micros. Nadie aceptó, pero se desde hace tiempo (de cuando programé un 16F84) cual es el resultado. Y es que los compiladores modernos para micros decentes, dan un resultado que difícilmente se consiguen en ensamblador aún dedicandole el doble de tiempo.
Respecto de la tabla que comentas, el problema es que hay que hacer dicha tabla, y si la haces para meter directamente el resultado del ADC, necesitas 1024 entradas en dicha tabla. Hacer una fórmula matemática que use sumas, restas y multiplicaciones de números enteros ocupa menos que dicha tabla, con algo de conocimiento. En ese punto, el C es muy ventajoso.
Un recurso habitual, más 'cutre' que el sistema que yo propuse, más limitado, se basa en 'linealizar' la NTC (o el sensor que utilices), donde se supone que la temperatura será directamente proporcional al valor de entrada, es decir T = K*ADC + C. Es decir, que con una multiplicación y una suma se arregla todo.
A veces hay que dividir, pero en tal caso el truco suele pasar por usar un multiplicador que te de un valor elevado que luego puedas dividir por una potencia de 2, que se consigue simplemente haciendo shifts.
La imaginación y las matemáticas de bachillerato son las herramientas básicas. No hay que complicarse mucho la vida.