While Loop or setWatch?

So MCU can request a I2C communication window when this pin goes down. That is the reason why while loop will not be an infinite.

'Infinite' at your terms: no - but in Espruino's architecture: infinite enough to qualify... and even more so if you even think remotely to put something like this onto an ESP8266EX chip.

For sure Espruino supports interrupts... directly in it's firmware, and puts a marker into the event queue as you define in the setWatch()... that makes it so easy and simple to use. Your application JS code (function) will be called as soon as nothing else more pressing is going on and your last event driven application JS piece has completed.

In Espruino, everything is event driven... either by a pin signal or a time (which is a timer signal). I'm not sure you really need inline C. But feel free to be its guest and share your experience.

As stated - everything in Espruino is event driven / has to be event driven - even a polling is event driven: a time - setTimout() or setInterval() - sets up timer that will fire and in the end pull the 'spaghetto' out of the plate of (code) spaghetti and mumpf it. Just make sure - in order to be a good 'spaghetto citizen' - its (execution) length does not qualify for infinite or resource hogging, because as long as your one spaghetto is in process, no other spaghetto can run... Be aware that many drivers / connectors to sensors use modules written in JavaScript... so - for example - receiving data will not happen - until the 'data read' event is first in the event queue and next for execution.

This - TSO - time sharing option - is one of the oldest architectures... around with the first main frames that gave multiple users so called 'simultaneous terminal access' (vs. console access, which in the early days was the only terminal): a 'pseudo multi-/parallel- tasking' that is done in JS in Espruino as well as in the Browser (in the Browser only until recently...): an application process or flow is divided up into many short code pieces (spaghetti) where one plants the seed of the next(s) one(s) by setting up an timer or pin interrupt (javascript) handler. This way it seems to us 'slow' humans as if things are handled in parallel / multi-tasking, where when closely looked at, each piece is happening so fast that we feel a particular application has the processor's attention at all times.

Benefit of this setup is that there is no complicated locking/synchronization required between the apps... it's almost like transactional: a once started piece of code always finishes and what is. done is done without any other application interference... The price pay: you pay upfront by thinking thru the process and identify the pieces and their triggers (interrupts they setup for the next one).

Speaking of interference: if you go into async yourself, you are on your own - or to bare metal... and in the end: you have changed nothing: it is still single threaded... and if your thread takes too long to relent, some one else - other application thread - will pay for it.