I hope my answer helps you a bit. Let me start of with option 2, busy waiting:
You may know that in programming, asynchronous (trigger-based) waiting is preferred to busy waiting, because it consumes less cycles in you CPU, so the code will run more in parallel and usually faster. That is, because the operation system usually knows how to properly "wait a certain amount or until a certain event".
Just in the same way, in a BPM, you would not pay your employee half of the time to just sit somewhere and actively wait until something is done. As a real example, let's take a waiter in a restaurant. Say they have to heat up meals which were prepped yesterday with exactly 600 watts of power and for 2 mins and 21 seconds. It would be nonesense to have the waiter sit in front of the microwave and have them wait with a stopwatch to stop the microwave when the time passes by. Instead, they could be serving a customer in the dining room, and come back as soon as they hear the acoustic signal of the microwave. (multi-tasking). Also, if the time ever changes - let's say bigger portions, thus 3 minutes - then the work flow for the waiter doesn't change: they still wait for the bell to ring, having 39 seconds more to server customers. With busy waiting, you would have to change the workflow (tell the waiter to check for a different time span on their stopwatch).
Compared to all that, lets take the first approach: It is computationally more reasonable and also from a business perspective it makes more sense. The trigger itself can change (e.g. from a timed trigger to an email trigger from your boss), but the triggered event - and thus proceeding to the next step - stays the same.
