Operations vs. tasks
Apple's study focused at the wrong level of work. Pasting spreadsheet cells is not a user task, it's an operation at a low interaction level. More meaningful productivity has to be measured at a higher level, where users string together a sequence of operations to achieve their real-world goals.
With spreadsheets, for example, one of my recent tasks was to update a conference budget to reflect the option of adding another day of seminars. Such a task might well involve operations in which users would identify the cells containing an existing seminar day's expenses; copy these cells; paste them into a new day's area; and update the new cells to reflect the differences between the two days.
True worker productivity in this example would be determined by how quickly users could arrive at the new budget. Interestingly, a bigger screen would benefit many of the task's other operations. For example, it's faster to identify a big budget's relevant elements when you can see all of them at once. It's also faster to compare two potential budgets if you can see both of them together in one view. I don't question that bigger monitors are better, I'm simply pointing out that we can't trust Apple's study to estimate the magnitude of the benefits.
The distinction between operations and tasks is important in application design because the goal is to optimize the user interface for task performance, rather than sub-optimize it for individual operations. For example, Judy Olson and Erik Nilsen wrote a classic paper comparing two user interfaces for large data tables. One interface offered many more features for table manipulation and each feature decreased task-performance time in specific circumstances. The other design lacked these optimized features and was thus slower to operate under the specific conditions addressed by the first design's special features.
So, which of these two designs was faster to use? The one with the fewest features. For each operation, the planning time was 2.9 seconds in the stripped-down design and 4.6 seconds in the feature-rich design. With more choices, it takes more time to make a decision on which one to use. The extra 1.7 seconds required to consider the richer feature set consumed more time than users saved by executing faster operations