Blockly “compiles” to ECMA Script 2022, which is run by the JavaScript Scripting (GraalJS) add-on.
GraalVM itself does not support 32-bit, however GraalJS is running on 32-bit up to some version (in fact keeping 32-bit support is holding me back from upgrading GraalJS to a newer version).
With Blockly switching from NashornJS to GraalJS, several users reported that the initial loading of scripts takes really long, which is because the helper library is injected into the script.
Therefore this issue affects all JS Scripting and Blockly users (as @Larsen already said), which of course is not all openHAB users.
Running on 64-bit, no matter whether on GraalVM or OpenJDK/Zulu, seems to really improve the performance of GraalJS (thx to @stefan.hoehn for doing some tests, see [jsscripting] GraalVM's optimised compiler or find another solution · Issue #15600 · openhab/openhab-addons · GitHub).
Given the fact that Jython might go away at some point in time and Rules DSL is IMO outdated (@rlkoshak if you have a better idea how to word this, this idea is really welcome), I feel that both JS Scripting and Ruby Scripting are promoted as go-to solutions when creating new rules.
After veryfying the performance difference between 32-bit and 64-bit and measuring the RAM usage of 64-bit and having a look at the other possible solutions, I would rediscuss this.
I could also imagine having a split solution, that recommends different OSes for different models.
BTW: 64-bit would also allow the installation of InfluxDB 2 on Raspberry Pi.