No, you're not understanding mine. Nobody builds an OS/system expecting that every executable is perfectly well behaved with zero bugs and zero ill intent. Applications are allowed to run code. JITs just run code in that same process. They are already limited to what the process was already allowed to do in the first place.
And my point about C is literally that even without a JIT, applications can still have arbitrary execution vulnerabilities.
A JIT intended to run untrusted code as part of a sandbox, like a browser, is a big risk. But that's because of the untrusted code part, not the JIT. By comparison, something like a Python or Java JIT is as near as makes no difference completely risk free. The JIT is working on exclusively "trusted" code. Same basic concept applies here with this database usage.
If a process is allowed to execute code, it's always allowed to execute arbitrary code as well. Those two are fully intertwined, be it via dynamic executable code, ROP chains, because it has an interpreter, or because the initial binary itself already is the malicious payload in the first place.
To the OS those are all identical scenarios, it's irrelevant what caused the arbitrary code execution to happen.
