On the face of it, event-driven programming seems far easier to explain. "This code will run when the button is clicked" seems obvious, and similarly, visual environments that favour this technique seem relatively intuitive:
(source: mit.edu)
It would seem obvious to explain that the code below that block runs when the sprite is clicked.
Similarly, in Node.js, an event-driven programming language:
app.get('/', function (req, res) {
res.send('Hello World!')
})
With some basic knowledge of the framework used (ExpressExpress), you can tell that when the / route is accessed, Hello World! will be sent.
So, without looking too deeply, event-driven programming is the obvious choice. But, this isn't the end of the story. If you're not used to event-driven programming, the fact that your code might not run in the order you expect is very confusing.
fs.readFile('foo', 'utf8', function (err,data) {
console.log(data);
});
console.log('Hello!')
Two things will print here: the contents of foo and the word 'Hello!'—but which prints first? The answer is: you can't tell, despite the intuition that many students have that would suggest the order is file then 'Hello!'.
Event-driven programming starts to encounter a lot of these 'gotchas' because it's difficult to predict in which order things will happen. Ideally, each event wouldn't need to consider any other event happening, but in practice it is necessary.
Let's say you wanted to end the game if your spaceship was touching two others at once. With events, you could need to subscribe to 'Touching [spaceship1]?' and 'Touching [spaceship2]?' and synchronise them (not terribly straightforward). But polling like so would be far easier—for each update loop, just test if(touching(spaceship1) && touching(spaceship2)).
Getting to your original question, I would personally introduce event-driven programming first, since it's so straightforward for trivial use-cases. As the problems start to appear with events, then introducing polling in an update loop would be wise. Most of the major introductory programming environments seem to follow that (Scratch -> Greenfoot, etc). The same principle should apply to your own environment, I think—consider your audience and what they'll be using your own environment for, and you'll have an answer that suits you.
You might also find Polling vs event driven input on Game Development Stack Exchange interesting for reference on the problems faced by professional game designers regarding events vs polling.
The only alternative, perhaps, would be to batch events from inputs so that they can be handled in the next update loop—that's something to consider if you're looking for another way of handling the issue, but it is more complex than the others.
