I think that’s only true on paper; in practice it’ll be true only when you have competing reads (at a thousand-foot view) and it might be possible to algorithmically bundle a portion thereof. It originally let SCSI controllers attached to spinning rust HDDs optimize physical manipulation of the disk heads to optimized queued reads of data in a “traveling salesman” sort of way, but modern nand flash can only internally read a full page at a time (which may be much greater than even the apparent physical sector size) anyway and with a strictly constant cost regardless of the “physical location” of the data on the non-existent platter. Old drives had optimization constraints like higher sequential read speeds at the outside of the platter (more bytes per physical rotation) and extremely pathological cases for data written to the innermost tracks of the platter. Individual requests were much finer-grained and the latency was much more varied, so a request from app/thread X for as little as 512 bytes from one location could be cheaply piggy-backed on an existing request from app/thread Y to read multiple megabytes from a physically proximate source that would otherwise have seriously delayed or starved the queued waiting read while the outstanding request was serviced.

In fact, one consistently sees higher bulk IO numbers when using physical media that has been formatted with a large sector size compared to the old 512 byte fixed emulated size. You’d routinely see lower latency and higher IOPs with 4kn (HDDs or SSDs) than you would with 512e disks, even with SCSI or AHCI controllers that featured similar pipelining support to today’s NVME controllers (or even if you place a spinning rust HDD behind NVMe today!).

Mostly true but as someone else pointed out it’s still better to issue a single large multi-page contiguous read than the same read broken down into separate requests because the I/O queue isn’t infinite. So both the Linux kernel and the SSD microcontroller still benefit from merging contiguous requests on their end. However, if you issue it correctly at the application level that’s still going to be better in that you’re never going to encounter a situation where you accidentally don’t get the desired coalescing.

> disk heads to optimized queued reads of data in a “traveling salesman” sort of way

Luckily the read heads only have one degree of freedom, so the "elevator algorithm" is sufficient: https://en.wikipedia.org/wiki/Elevator_algorithm