How are block nested loop joins optimised for disk reads?
To answer your first question, it depends on if the RDBMS has stored the data as rowstore or columnstore. For a rowstore table (much more common), pages are organized into rows. You would read all columns for a row into memory. For a columnstore table, pages are organized into columns. You could just read only the columns relevant to the query into memory.

To answer your second question, why must "recording" be the outer table? What if the "uses" table has zero rows? Wouldn't it be more efficient to pick that as the outer table? Putting that aside, it's a very general question. You haven't listed a specific RDBMS platform. If there are no sufficient indexes the "recording" table then I would expect the optimizer to generally filter out pages using the filter on the "made" column before performing the join. I can't think of an advantage in doing it another way. 

Why does the query planner need to calculate the number of disk page reads done? I don't follow that part.