Proposed solution:

Your scenario of a 140-second timeout with 3 seconds per image yields a maximum processing capability of only 46 images before timeout. Therefore, I could make import immediate if 25 images or under. Otherwise, schedule a task that processes the images in batches of 25 (or a configurable option value). Or, sense server timeout and whatever images have not yet been processed, re-trigger the task with the remaining images.

The problem is it really depends what images are imported. People often nowadays don't think about it when importing enormous megapixel images from smartphones. I don't think it's reasonable for us to try and compute it.

How about this...

1) Rework the code so it can be run both as a task and from the module.
2) Make it so that code can start importing from an offset into the set of images being imported (needs to consider that there may both be multiple files and archive files)
3) Import immediately, but if (time() - $_SERVER['REQUEST_TIME'] > 20) create the task, called with the offset

For the record, we decided to ignore the issue about tasks being slow and hence not wanting small import jobs to run as tasks.
Instead, we're implement a new way of Cron executing whereby it stays resident in a loop, so tasks can be identified and finished very quickly. Additionally, some kind of console for monitoring task progress.