credo che il punto che ti sfugga di più, Linkinf22, è che se un'azienda deve sviluppare un software e la microsoft gli fornisce uno strumento che gli permette di metterci 1/10 del tempo con 1/10 dei bug grazie al codice gestito, l'azienda non ci penserà DUE VOLTE prima di utilizzare questo strumento.
Il motivo per cui ancora oggi ci sono programmi grossi non scritti in .NET è che non è possibile fare il porting in tempi brevi di una considerevole quantità di codice. Inoltre bisogna anche considerare il know-how interno all'azienda del team di programmatori di quel software: se sono tutti esperti C/C++/Delphi ha poco senso istruirli su una tecnologia nuova e imporgli di portare il tutto su quest'ultima.
Senza considerare il fatto che un antivirus, tanto per citarne uno, è un tipo di software che poco si presta ad essere scritto in .NET, a causa dell'interazione a basso livello con il sistema operativo, la velocità al primo posto e la resistenza agli attacchi dei virus.
La tecnologia COM invece è un modello ad oggetti (Component Object Model) che permette di interagire con blocchi di codice funzionale già pronto SENZA passare per le API... ma se ci pensi .NET è un'evoluzione di tutto questo
Ad ogni modo microsoft non abbandonerà mai completamente il layer nativo, non gli converrebbe mai proprio a causa di quei software basati su di esso che altrimenti resterebbero tagliati fuori dal sistema.
Poi, un'ultima cosa su le tue affermazioni dei "sapientini", personalmente credo che tu, giustamente, sollevi certe questioni proprio perchè NON ci hai mai lavorato con .NET. Ma per "lavorato" io intendo "farci soldi" e "mangiarci", non "usato".
Se veramente mi stai venendo a dire che "[con] le [API] win32 ho notato vantaggi, più libertà" ti posso solo dire che non hai capito nulla.
Ti voglio vedere sviluppare un gestionale con MFC o direttamente con le API, ti voglio vedere sviluppare una piattaforma web in CGI nativo, ti voglio vedere sviluppare un'utility idiota nativamente (1000+ righe di codice) al posto che in .NET (max un centinaio).
Se veramente il tempo è denaro, appunto perchè ci devi mangiare sopra, NON te ne usciresti mai con certe boiate.
Sul fatto che sia interessante utilizzare le api non ti do torto, è giusto capire come il sistema, alla fine, gestisca le cose. Inoltre, come ho già detto, esistono software e software, alcuni si prestano ottimamente allo sviluppo .NET altri decisamente meno. La regola è che se un'applicazione deve interagire a basso livello con il sistema operativo o ha bisogno di altissime prestazioni in ambiti time-critical è NECESSARIO utilizzare codice nativo, sono il primo a dirlo.
Però dove sta l'intelligenza di un programmatore, sta nel realizzare le funzionalità CORE native dell'applicazione in C/C++ ma l'interfaccia grafica, l'accesso a servizi web come SOAP o WCF, interazione con database IL TUTTO in .NET . In questo modo prendi il meglio di entrambi i mondi: prestazioni al 100% sfruttate dell'hardware, interazione con il sistema a basso livello ma anche velocità di sviluppo e testability delle parti meno critiche come la GUI, accesso a servizi e quant'altro.