My current take on this. The "business logic" should not be written in Turing complete languages, but rather composable languages based on simple type theory. So the "business logic" would be limited in what it can do to compromise the system. And then it should be deployed on the execution platform, which is a different concern altogether.
I think using TC (like Java or Javascript) languages for everything is a wrong direction in SW engineering. I think we want to have TC languages for the low level tools (like parsing data, algorithms), and for the execution engine, but we want to compose these in languages that can easily compose, and thus are restricted.
IMHO there are at least two different categories of compositional restricted languages. One is data manipulation languages, that describes how to manipulate data in the schema, regardless of the platform or physical data representation (I really like what David Spivak is doing in this area with categorical databases). The other is system architecture languages, which shows how are these data manipulations executed, and how they compose into transactions, and more broadly, software systems. The former category concerns with how the schema of the data changes, and the latter category concerns with how are the data in the same schema exchanged at the boundaries of different SW systems. (There are probably also useful categories of restricted languages to describe UI and visualizations.)