Absolutely.
The thread pool size, by default, is three. That is, once three tag event scripts are running, or sleeping, or waiting on a network reply, all other tag events have to wait.
The pool size can be reconfigured to be larger, and that is reasonable for very large systems, but tag events should still be designed to execute as near instantly as possible, with only gateway-local information.
Any tag change script that needs to perform anything complex needs to be in a project-based gateway tag change event, not an event defined on the tag.
Algorithms that need delays must be implemented as state machines via gateway timer events.