Voy a discernir en un par de detalles de lo que mencionas.
Cita: No es asi, es lo mismo que con cualquier otro QB de los que mencionas mas abajo solo cambia como están diseñados y sus interfaces.
No es la impresión que me lleve al leer la documentación, pero como no lo he usado, confiare en tu palabra (hasta que lo pruebe por mi mismo).
Cita: Falso, pueden ser usados de forma independiente, algunos usan cosas de terceros como Propel pero son facilidades. Tampoco te obligan puede usarlos a diferente nivel de abstracción segun te convenga, las molestias están en el nivel de preparación del programador.
Yo no lo veo asi.
Si los saco y los quiero usar por separado con otro conjunto de librerías hay que hacer algunas adaptaciones, como tu dices, depende del nivel del programador si hacerlas se convierte en una odisea épica o solo es juego de niños.
¿O acaso usar Doctrine con el QB de Laravel o viceversa solo se trata de cambiar los archivos de carpeta?
Eso es lo que la abstracción te vende, pero no lo que ocurre en la practica.
Por supuesto, si se hacen las adaptaciones correspondientes pueden funcionar correctamente, pero volvemos a lo anterior.
Como programador si agarro un QB (o cualquier otro componente) es porque quiero usarlo, no adaptarlo o modificarlo.
Cita: Son eficientes y están perfectamente organizados y ese centenar de archivos molestos tienen un razón de ser. la demora es es algo que no tiene menor problema todos los ORM te permiten trabajar a diferentes niveles de abstracción; asi que si necesitas mejores tiempos estos QB son suficientemente felxibles para hacer lo que necesites.
No pongo en duda la importancia para el buen funcionamiento de cada linea de código en cada archivo del componente. Pero no es lo mismo levantar una clase que 20, es tiempo muerto que se pierde parsenado, compilando, definiendo, instanciando, es memoria que se gasta en guardar definiciones y referencias, etc. Cuando hay muchos usuarios simultáneos la suma de estos tiempos muertos se vuelve significante, ¿Y que haces ahi? bajar el nivel de abstracción, remover clases e interfaces y trabajar a un menor nivel, entonces, ¿para que quiero un QB gigante si cuando necesito respuestas rápidas tengo que reducirlo únicamente a su núcleo? ¿no seria mejor tener de entrada solo el núcleo, pero que sea lo mas completo posible?
Cita: Falso, si optimizan sus consultas de forma diferente cuentan con una forma de construir la gramatica que soporta un RDBM especifico y tener la consulta preparada para su reutilización.
Voy a informarme mas sobre el tema antes de responder a esto, pero las pruebas que he realizado con varios QB no hacían uso de esta optimizacion en consultas repetitivas.
Cita: Vuelvo al punto no es el ORM o el QB si no la mente de quien lo usa lo que crea una ventaja o una limitación.
Claro que no, tampoco lo es el FW ni el lenguaje, los programadores con buena mente logran ventajas programando sitios web en hexadecimal, para ellos no existen limitaciones.
Como la gran mayoría somos personas limitadas, necesitamos de un FW que nos imponga la menor cantidad de limitaciones posibles, ya son bastantes las que nos ponemos nosotros mismos.
PD: Mas allá del discernimiento, voy a investigar los puntos que mencionas por si estoy equivocado.