No, this is a bad idea, since this allows users to easily run a DoS 
attack against Kronolith.

I see that it does make sense to use a shorter timeout for non-AJAX requests.
Would it be feasible to make the timeout configurable for the users 
via prefs like I did in the attached patch?

This is intentional, see 
https://github.com/horde/horde/commit/1d271b4c55ae04fee314c28a798b88ceb6572d1a
In portal and basic views, all events are retrieved at once. We cannot 
use a higher timeout there, otherwise the user may have to wait too 
long for the whole page to return. The timeout has been relaxed in 
Ajax view only because loading happens asynchronously there and the 
interface is still usable while the events load.

When an external calendar takes between 5 and 15 seconds to respond, 
it will work in the dynamic kronolith view, but not on the Portal page 
if a calendar block is used

This is because in _getDriver() in 
kronolith/lib/Ajax/Application/Handler.php, we have

         if ($driver == 'remote') {
             $kronolith_driver->setParam('timeout', 15);
         }

But for the function listEvents() in kronolith/lib/Kronolith.php, we have
        $driver = self::getDriver('Ical', $url);
        $events = $driver->listEvents(...);

which uses the default (hard coded) timeout value of 5 seconds. This 
could be fixed by inserting $driver->setParam('timeout', 15); in the 
above snippet, or (better?) improve the method getDriver (which 
already includes a branch for $instance instanceof 
Kronolith_Driver_Ical).

Would it also be good to have those timeout values configurable?