What is the purpose of a large disk cache if the page cache is always larger?

You seem to focus primarily on the sizes of the host's page cache and an HDD's onboard cache. But the benefits of cache hits are mitigated by the (operational) costs.

The page cache could simply retain the requested blocks that have been read from the HDD, and hope that retaining them will result in cache hits if any of those blocks are requested again. The acquisition cost of such cache content is essentially zero, whereas when "the OS ... handles read-ahead" the costs incurred are the read operations from the HDD. This cost can be exacerbated and become a performance penalty if the read-aheads are excessive and have a low cache hit rate.

In similar fashion the HDD could also retain blocks already read in its cache. But the hit rate on those blocks should be close to nil with a reasonably effective and efficient OS. But the HDD could also populate its cache by acquiring read-ahead blocks at no cost or perhaps a small time penalty (i.e. deferring the next operation).

A disk operation requires an access time before the drive can perform the actual read/write operation on a sector. The three primary phases are (1) seek time, (2) head switch time, and (3) rotational latency. A sequential operation typically means that seek time and head selection time are zero. But the timing of when and where on the track that the disk controller actually begins reading the disk track is typically random.

The worst case scenario (for rotational latency) is the controller just missing the start of the target sector, and waiting for a complete revolution is required for the target sector to come back around. Normally this waiting is dead time, wasted doing nothing, lengthening the access time. But if the sectors following the target sector were read (instead of ignored) by the controller and saved in a cache, then a read-ahead can be accomplished while performing a normal operation. This read-ahead can be perform at absolutely no time cost to the host, i.e. essentially for free.

The number of possible sectors for a read-ahead depends on (a) the position of the target sector on the track (i.e. relative to the start/end indicated by the index mark), and (b) where the controller begins reading the track. Note that with zone bit recording, the number of sectors per track is variable, and the CHS address of an LBA is unknown (and typically irrelevant) to the host.

Given the previous worst case scenario of the controller just missing the start of the target sector, the worst sub-case scenario (i.e. the worst of the worst) is when the target sector is the last sector of the track. That means that there are zero sectors for a read-ahead. A best sub-case scenario (i.e. the best of the worst) is when the target sector is the first sector of the track. That means that almost a full track of sectors are available for a read-ahead. But for a random LBA and an arbitrary read start, the number of sectors that can be read-ahead for zero performance penalty should fall between those two extremes (but a non-linear probability and skewed toward zero).

If the disk controller is intent on populating its cache with read-ahead blocks, then a read operation could be extended past the target sector whenever the controller begins reading the track before the target sector (rather than after). Such an extended/prolonged read would only be "free" when there are no other pending disk operations queued up.

Bottom line: a disk controller could perform read-aheads and maintain an on-board cache with no performance cost to the host.

There is a white paper which claims that a major benefit is the ability to populate the buffer with "free" read-ahead and read-behind that is obtained by the head while it is still seeking the requested data:

Yes, such reads can be "free", i.e. no additional time to perform.
The utility/benefit of "read-behind" is questionable (but of course possible).
Your use of "seeking" is a poor word choice because that is not the access phase that is active at that point.

The host does not have visibility into when it is free to extend a read.

Emphasis mine. Is this the primary purpose?

I would assume so.

As in the question, I'm limiting the answer to considering read access. As you mention, the purpose of the cache is more obvious for writes. One might go as far as to say that write caching is the purpose and read cache is a side benefit.

The host does not have visibility into when it is free to extend a read.

Emphasis mine. Is this the primary purpose? If not, what is?

I'm not sure what level of evidence would be sufficient to say this definitely, but I'd say that yes, this is the important factor during reads. For the hard drive, it is always free (if power usage is not considered) to read something when there is no active request.

For the operating system, the equation is different. If the operating system starts a read request for read ahead, the drive will complete that, even if it delays other requests. The NCQ command set defined in ACS-3 helps a bit by letting the drive reorder the requests, but the supported priorities are only "normal priority", "deadline-dependent priority" and "high priority". The is no way for the operating system to issue a request of "do this if the drive is otherwise idle". It could abort the read-ahead request, but it might end up aborting a request that is already almost complete.

Considering the relative sizes of the page cache vs. hard drive cache, the hard drive can speculatively read any nearby data until a new request arrives. It does not have to care about holding onto old data that might be accessed again, as the operating system cache will handle that.

Manufacturers usually increase cache size with increasing drive capacity. This could be due to number of read heads in the drive. The read speed increases and therefore you get more free read ahead during the same time period of operating system latency. On the other hand, it could be a result of market analysis of price vs. performance optimization for lower and higher end drives. For SMR drives, the lower write performance probably dominates the need for a large cache.

It is not only the size of the cache. Internal disk cache is much "closer" to the source of information and (usually) is much faster than OS cache. Also it store information from near sectors (related to target read) and can be helpful in some cases.

Moreover the controller/firmware know much more about the disk internals and can more efficiently manage cache for disk itself.

At the end this is typical multilayered storage/cache and going to upper layers you loose "connection" with the source and get more abstract view to the information.

Frame Challenge.

I can see how a small buffer would be necessary to match the raw read speed to the speed of the SATA/SAS interface.

"a few hundred megabytes" is just 3% of 1% of a (relatively ancient 2007) 1TB drive. It's just 0.3% of a 10TB drive. That's a pretty darned tiny buffer cache.

That original SATA and SAS could drain that "few hundred megabytes" in just two seconds. Current versions can drain that "few hundred megabytes" in a fraction of a second.

Thus, I think the whole premise of your question is flawed, because "a few hundred megabytes" is what you say you can understand: a "small buffer (that is) necessary to match the raw read speed to the speed of the SATA/SAS interface."