After having studied Qt Code, I think it's like this:

1. You only have one thread (default)
Only one part of code can be executed at the same time. So the slot can't be executed two times in parallel. As long as the called function is running, it isn't possible for Qt to return to the event loop. So also no QTimerEvents (internal Implementation used by QTimer) will be sent to the Object. This, again, leads to no timeout before the event loop is reached. In the event loop, times are checked for all activated timers. There, Qt will notice that the Timer has timed out, send a QTimerEvent, which is caught by the QTimer. QTimer, again, emits timeout(), which is executed immediately if you haven't state which sort of connection you want (Qt::AutoConnection). So the game starts again with the called function being executed.
If you create a SharedConnection, the function will be executed in the event loop - not immediately. But this doesn't change the situation, because the event loop must do one thing after another and it doesn't check the timers while the function is being executed.

2. You have the QTimer in one thread and the called function in another thread
I haven't verified this, but this is what I think will happen: The Thread containing the timer - having its own event loop - will be able to queue the timeout-Connections immediately when the timer times out.
The other thread will execute all invocations received, no matter how long this takes. So I think it would be possible to send 1 million invocations in a few seconds from thread one to make thread two work for a whole day (theoretical ).