Option #1 is a very reasonable method with making games. Making a variable which can hold a very big number and incrementing it every frame is an easy way to make multiple timers which can be reset when needed without messing up the flow of the game. I personally don't see the need of checking the parameters every other few frames (unless it's intense collision detection) because this easily creates bugs. While it can sometimes be annoying to pour through tons of if statements, if you lay everything out in an orderly manner, it's quite effective. This is my preferred approach.
As for option #2... I think this is more of an option for programming teams. While it makes the code neat and somewhat easy to understand, mess up in the data management in one place or with one sequence of events and the game wrecks itself completely and the user has to lose their current progress, reset the game, or uninstall and reinstall depending on the structure and how many disaster possibilities there are. This is just with my own experience - I've completely messed up the structure, gotten confused, and ditched my entire programs by doing this.
Obviously, both methods have upsides and downsides but both methods can work. Depending on your skills in certain areas like lists, other data structures, and/or creating flow control, you may find that one way is way easier than the next. There's also nothing wrong with combining these methods. You may find that most of the game can be done with if statements, but you'll need more event lists for maybe a continuously changing game arena. Although often you will want to lean towards your skills, it really just depends on what you're programming.