Ok, gotcha and no offense taken. We are here to listen.
When I joined HALion Team, I was of the same opinion as you (still am). I am a pure data, supercollider, Nord Modular kinda guy. So I was pretty stunned, just like you.
To be honest, there is a mix of reasons why it is the way it is.
One reason, and one of the reasons why HALion sounds so good, is the fact that modulation inside the zone is audio rate (many other instruments, just update parameters every 32 samples or so). If you try to apply this to parameters that, for example, reset an oscillator, you get ugly artefacts.
So beauty is one consideration. I know that some people like artefacts and dirt, but in HALion, this should be added deliberately to your sound, not by accident. Determinism is a principle in the design choices. We sometimes stray away from this principle, like x-lfo for example, but if we do, it is (usually) deliberately.
Another consideration is performance. Other than most modular environments, HALion is made to host large sample libraries. Allowing entirely free, audio rate modulation routing AND a modular structure would just get any computer to it’s knees (play with the amazing vcv rack for a while, to find out what I mean, and that is mainly monophonic). HALion also needs to be able to run many instances, as we also have to keep something like orchestral project templates etc. in mind.
That said, we are always looking for ways to make this engine more flexible, so never say never.
In theory, there is already the possibility to create a global modulation matrix using the scripting engine, but you will run into the artefacts and slower update cycles stated above. So if anyone in the community hears their calling for that kind of midi module, there is an opportunity for scripting and macropage heroism 