The PHP script start sending data (nginx reads) then pauses (computing time) then send more data (nginx reads). If the pause lasts longer than the specified time the connection is dropped.

I think it's a correct interpretation.
And it's easy to test: write a simple php-script with some sleeps between echos and flushes. (Can't do it myself at the moment).

Isn't the "whole response" duration that matters?

To me personally, the fastcgi_read_timeout approach is more appealing:

• If you server is under a high load with fixed timeout it will definitely fail from time to time. Users will be irritated, they'll refresh... send another request... And you server chokes even more, never fulfilling any of user's requests.
• But if, no matter the load, you server shows it is still alive and trying hard to fulfill client's requests then it's up to them to decide to wait or to abort. Much better!

And what parameter sets a limit for that?

max_execution_time in php.ini or

fastcgi_param PHP_VALUE "max_execution_time=1000";

in your NGINX config