If you know the seek, rotational delay and transfer rate, how do you calculate the transfer time for a file with a given total size and cluster size?
You cannot know this because you don't know where physically on disk any given file is; if the sectors containing the file (contiguous or not) are closer to the spindle, transfer rate will be much slower than if the file is physically located in sectors closer to the outer edge of the platter.
In addition, cluster size is irrelevant in this context; this is the minimum number of sectors used to store a file, and is a factor of the filesystem, not the disk.
UPDATED to answer questions in comments:
Rotational delay is almost always present; the disk has to turn enough such that the first sector of the cluster is under the read head before you can start reading it. If the file size is equal to 1.5 times the cluster size, the file will occupy 2 clusters, and the "extra" 0.5 clusters will be wasted (referred to as "slack space") -- decreasing cluster size helps reduce slack space, at the expense of more I/O overhead to account for the greater number of clusters the filesystem must keep track of. A cluster is the smallest unit of space in the filesystem ("tail packing" notwithstanding).
More info on tail packing: en.wikipedia.org/wiki/Block_suballocation
Most people store a mix of file sizes in a filesystem, which is why a middle-of-the-road cluster size (such as 8KB or 16KB) is usually the default. A given filesystem's default cluster size depends on the size of the filesystem being created.
If you know you'll be storing loads of tiny files on a filesystem, you set up the filesystem with a small cluster size to minimize slack space (as long as the associated performance hit isn't an issue for your application). If you know you'll be storing loads of huge files (such as videos) on a filesystem, you set up the filesystem with a large cluster size to reduce I/O overhead from bookkeeping all the cluster allocation info (such as the MFT in NTFS).