If you're willing to throw out security and use one of the many EVM clones, then you're just better off using a database. You're giving away the main value add and are just left with inefficiencies.
The devil is in the implementation details, but if we're talking about eBPF vs. EVM... one of them was designed for deadlock-free execution of untrusted code in-kernel, and the other is EVM.
Though, for smart contracts, I think we're best off with a graph reduction execution model, where the contract is presented its initial state and an array of the output contract states, and the contract graph evaluates to True i.f.f. the outputs are an acceptable end-state given the initial state. The client code would propose the new state, along with a compact representation of the path taken through the graph. (The path represented as the index of each branch taken at every OR node in a pre-order traversal of the graph.) The client-side execution to find a True path through the graph might not be efficient, but the on-graph verification is fast, and the format lends itself to a declarative contract description.
The tradeoff is, of course, that scripts become much harder to implement, as you can't depend on global state.
[1]: https://iohk.io/en/research/library/papers/the-extended-utxo...