Also bei SQL gibt es immer einen gewissen Overhead den es bei Native I/O nicht gibt.
Deshalb kann SQL durchaus "langsamer" sein.
Wobei wir hier in bereich von milli sek. sprechen, wenn eben z.B. der Zugriffsplan erstellt wird.

Wenn ich ein SQL sehe welches zu langsam wäre, vergleiche ich nicht ob es mit Native I/O schneller wäre, sondern analysiere warum es langsam ist (fehlende Indice, schlechte struktur des SQL Statements, usw.).

Ich habe auch einmal eine Client Anwendung in der 10.000de INSERT INTOs gemacht wurden.
Dies sollte beschläunigt werden und sebst bei einem simplen INSERT INTO mit VALUES konnte ich eine Performance steigerung durchführen nachdem ich die Struktur des SQLs geändert habe.
Sowas ist aber nur notwendig wenn man um jede milli sek kämpfen muss/möchte.

Ich glaube man muss bei Grundsatzdiskussionen etwas genauer hinschauen.
Meist (wenn nicht nahezu immer) geht es darum, dass Kollegen, sich in der Native I/O welt wohler fühlen als mit SQL.
Und dann kommt jemand daher und will einem aus der "Wohlfühlzone" reisen.
Da holt man jedes Argument was nur irgendwie möglich ist um sein Weltbild zu verteidigen.
Wenn man erkennt wo das eigentliche Problem liegt, und die diskussion dahingehend lenkt, so kann man (davon bin ich überzeugt) die beiden Seiten viel besser zusammen bringen.