The way the SQL Server typically works is that it will issue an I/O (read/write) and save the I/O control block and continue to do other work (on behalf of other connections). It'll periodically poll the workq's (network, I/O) and resume connections when their work has completed (I/O completed, network data xmit'd...).
Cooked I/O typically (again, SGI has something called directed I/O which allows I/O to go directly to user space) has to go from disk, to kernel buffers and from kernel buffers to user space; on a read. The extra layer with the kernel buffers is inherently slow. The data is moved from kernel buffers to/fro user space using bcopy(). On small operations this typically isn't that much of an issue but in a RDBMS scenario the bcopy() layer is a significant performance hit because it's done so often...
If your machine has sufficient memory and extra CPU capacity, you can realize some gains by having writes return immediately because they're posted to memory. Reads will gain from the anticipatory fetch algorithm employed by most O/S's.
You'll need extra memory to house the kernel buffered data and you'll need extra CPU capacity to allow bdflush() to write the dirty data out to disk... eventually... but with everything there's a cost: extra memory and free CPU cycles.
One argument is that instead of giving the O/S the extra memory (by leaving it free) to give it to the SQL Server and let it do its caching... but that's a different thread...
Some O/S's allow cooked files to have a write through mode and it really depends if the SQL Server has been certified on cooked file systems. If it has, it means that when the SQL Server opens a device which is on a file system, it fcntl()'s the device to write-through.