It almost entirely depends on the context of the function within the program and the program within its usage context.
Here's my general approach:
If only one event can happen at one time, especially if events are infrequent, use polling. This reduces the amount of function references needed when they would be unnecessary and also cuts down on the instantaneous overhead when an event occurs. This makes polling ideal for programs like timers, which are only waiting for one event to happen. Of course, one could also write a timer that schedules the buzzer at the appropriate time or one that binds a function that checks whether the correct amount of CPU cycles has passed every tick, but this uses references and possibly pointers where they are simply not needed. Polling is also ideal for graphical update (but not necessarily input) methods, where the screen is updated at a regular interval whether anything happens or not - otherwise the GPU would be receiving too many instantaneous drawing calls, especially in applications such as graphics-intensive games, and this way the FPS stays fairly consistent. Additionally, polling should be used when the output of the controlling function or event cannot be predicted: if you are designing a website and are creating a "Latest Threads" module for it, unless you are going to use something fancy like Pusher or React to update the module for all users, you don't know if you should update the module's HTML until you know the list of threads: in this case, polling must be used.
Event handling, on the other hand, is better for largely event-driven programs where, for example, the computer is waiting for users to perform a task. Event handlers are especially useful when multiple events can occur at one time or in quick succession, as event handlers are generally fired asynchronously, meaning that even if one event handler takes a whole second to finish executing, other event handlers do not have to wait that one second before running. This is ideal for the input aspects of video games, where a player could press the forward and left buttons at the same time, while also falling down a hole and being shot at. Each of these is at least one event, and it would be pretty bad if the game had to wait for the user to stop pressing the forward button before processing the left button before processing that they fell down a hole: they could theoretically delay the entire game by pressing a button. Event handling avoids this problem entirely, but blocking events can still be implemented easily enough if the programmer so desires.
Furthermore, despite appearances, polling-driven programs are generally less efficient than event-driven programs. Imagine the graph of time vs. CPU consumption for a purely polling-based program versus a purely event-based program. A polling-driven program's graph would show small spikes at regular intervals: every so often, it checks if a certain value is set and, optionally, if certain other conditions are met. If so, it calls a function and runs it. This would add an even larger spike whenever the event is called.
Now imagine the graph for a purely event-based program: when only considering the event handler, the graph is flat: no functions related to the event are being called. Once a user activates an event, the event calls the handling function, creating a single spike.
Now, in practice, an event-driven program would probably be more CPU-intensive simply because it is inferrable that it uses more event handlers which likely execute more often - but it would nonetheless be considered better practice to use event handlers.
The bottom line: It depends on context. Whichever one is more logical to use should be used. A program can use a mix of polling and instantaneous event handling as well, but there is a trade-off when you use a high amount of polling-based functions, even when they execute in their own threads: this will only solve the problem of blocking, not CPU consumption. Generally speaking, event-driven programs are more efficient if they are a feasible option, but polling-based functions are simpler and almost every program has to use them to some degree. Even the Microsoft XNA Framework uses an Update() function which is called every tick to update a window, as opposed to updating a single element when it changes.
For beginning users, polling is certainly easier to understand, but practicality should be kept in mind: even if you don't teach your students the how of event-driven programming, make sure to teach them the whats and the whys.