So after investigating a bit, it turns out the class name of the status bar is not stored in the compiled file and is replaced by a numeric index. That makes it more difficult to know which status bar is supposed to house the JavaScript commands. (In my example, the interpreter won’t be able to know into what number was @vaarple converted.)
One solution that occured to me: use CSS custom properties (a. k. a. CSS variables) to encode information into the class. (Since they don’t have meaning of their own and can contain arbitrary data.)
(style class @vaarple)
--vaarple-js-eval: true;
On the interpreter’s side, we look for the presence of the --js-eval property to know that a given class is the one for executing JavaScript commands.
Extending this concept, we could have arbitrary streams/windows that are configurable!
(style class @my-stream)
--vaarple-clear-on-enter: false;
--vaarple-name: side-window;
--vaarple-in-transcript: false;
%% And so on.
Of course it feels a bit hacky. 
The other solution is to plead Linus for a ENTER_STREAM opcode for arbitrary streams of text whose purpose is decided by the interpreter.
But I just discovered his answer here, and he seems to be against a feature to execute arbitrary JavaScript because it’s not future-proof.
So Linus, if you’re reading this, here’s my take: the point is not to be able to execute arbitrary JavaScript, but to be able to send arbitrary data to the interpreter (which can of course ignore it). I agree, it’s not future-proof and locks your story to a single interpreter, but that’s by design: the aim is to be able use Dialog as a middleware in a bigger game/engine (in the same vein than ink), and not only as a standalone story creator. In other words, to broaden the uses of Dialog. If an author wants to make a non-future-proof online game with Dialog, then that’s their choice and they accept the compromises it comes with. It doesn’t prevent others to make regular plain stories.
But the final decision is yours of course, and I respect that. 