If you use a 16K database block size over an 8K file system buffer size then all single block I/O requests will be serviced by the operating system as two 8K I/O operations which will be performed in series. That is, the second 8K operation will not be started until the first has completed. There are big inefficiencies here in terms of CPU usage and rotational latencies on writes. Reads do not normally suffer increased rotational latency, thanks to track buffers. However, if the disk is busy enough for another request to be interposed, then you may lose the contents of the track buffer and sustain two seeks before the I/O request can be completed.

I don't necessarily agree with the quote that "the database block size must match the file system buffer size exactly", but it must be an integer multiple of the file system buffer.