Barrapunto

1)Error. Esta comprobado que bajo las mismas condiciones FreePascal es tan rápido como C.
2)Error. El ejecutable en C incluyendo todas las bibliotecas que necesita es mucho más grande que el mismo programa hecho en FreePascal.
3)Es cierto que el linkeo estático desperdicia memoria, pero actualmente memoria es lo que sobra porque es abundante y barata.
Por otro lado, con respecto a los bugs: a) los bugs ocurren en lenguajes que fuerzan a los programadores a hacer cosas que provocan bugs, es muy improbable encontrar un buffer overflow en un lenguaje de nivel más alto.
b) si bien los cambios de bibliotecas pueden corregir bugs, lo más común es que el cambio de biblioteca signifique que no funcione ningún programa por estar hecho para versiones viejas que son incompatibles con las nuevas (cosa bastante molesta). Lo lógico sería mantener la compatibilidad hacia atrás. En cambio estamos constantemente con que no podemos correr los programas por problemas de que las versiones de bibliotecas no son exactamente las mismas.

Error. Esta comprobado que bajo las mismas condiciones FreePascal es tan rápido como C.

No lo he comprobado, pero en todo caso, siempre y cuando no utilices alguna de sus funcionalidades añadidas que afectan a la ejecución, como POO.

2)Error. El ejecutable en C incluyendo todas las bibliotecas que necesita es mucho más grande que el mismo programa hecho en FreePascal.

¿Algún razonamiento detrás de esa afirmación?

Dices, por un lado, que FreePascal (supuestamente) puede ser tan rápido como C. Por otro lado, el ejecutable es mucho más pequeño. Y aún por otro, la memoria sobra porque es abundante y barata, así que mejor si enlazamos estáticamente para que luego no haya problemas con bibliotecas.

Pues yo continúo tu razonamiento: por mi otro lado, los procesadores de hoy en día son muy rápidos y baratos, y por lo tanto da igual que FreePascal sea rápido. Por el mismo lado de que la memoria es abundante y barata, tenemos que me da igual que el ejecutable sea monstruoso, porque sobra el espacio.

Y por aún otro lado, para ejecutar N programas a la vez, usando notación algorítmica, tener bibliotecas compartidas supone, aproximadamente, O(1) en el consumo de memoria, mientras que de forma estática supone O(N). Cargar el ejecutable lleva más tiempo, pero no es nada comparado con el problema de que el consumo de memoria sea muchísimo mayor (y eso de que es abundante... lo será mientras no uses ejecutables estáticos para todo y no lances demasiadas cosas a la vez) produciendo más presión sobre la VM y más ciclos perdidos en gestionarla (¿Qué tal necesitar el espacio de intercambio? ¿Para qué sirve ejecutar rápido cualquier cosa si ante un fallo de página o cualquier otra incidencia el sistema tiene que perder más tiempo gestionando la memoria e incluso acceder a disco?).

Y para terminar con este punto, puedes producir ejecutables dinámicos, que por algo se han impuesto, y de paso, para rizar el rizo, haces lo que Free Pascal y los liberas de código no utilizado e información para el debugger.

si bien los cambios de bibliotecas pueden corregir bugs, lo más común es que el cambio de biblioteca signifique que no funcione ningún programa por estar hecho para versiones viejas que son incompatibles con las nuevas

Esto no es ningún argumento válido, se soluciona teniendo un buen gestor de paquetes con empaquetadores medianamente competentes.

Pascal es un lenguaje que tiene su utilidad, y con Free Pascal lo han extendido de varias formas que el lenguaje necesitaba porque sencillamente se quedaba corto para muchas tareas no triviales. Pero aprovechando esas extensiones, el código no puede ser compilado con otro compilador a menos que se ciña a no usar nada "nuevo" (yo pasé por Turbo Pascal, Delphi y gpc, y sé que Free Pascal soporta varias cosas de estos, si no todas, pero añade de su propia cosecha sin un estándar definido para todos).

El principal problema es que no es un lenguaje que ofrezca ninguna ventaja sobre C más allá de la sintaxis (lo cual es muy discutible) y algunas extensiones orientadas a objetos, y sí tiene varios inconvenientes muy grandes (poca gente lo utiliza, dificultad para obtener interfaces con otros componentes y bibliotecas del sistema, estándares poco o mal soportados, extensiones no portables, ¡ejecutables estáticos!, etc).

La mayoría de gente no lo usa para cosas serias, en definitiva, y los motivos por los que no lo usaba antes son los mismos por los que no lo usa ahora, y no parece que nada de eso vaya a cambiar. Y es que el lenguaje no fue diseñado para esto y se nota. C sí fue diseñado para lo que es hoy en día, y aunque ciertamente es más complicado y peligroso, ofrece un potencial mucho mayor.