We are always looking for ways to improve smart contracts. One of our primary design goals for any feature we add is to maintain or improve throughput, which currently is 1000 tx/sec with transaction finality of fewer than five seconds. This means we have to restrict some things in our smart contracts (size and opcode cost). We do not want a scenario where an app can be developed that does “anything” but kills throughput for everyone else. By adding limitations on both stateful and stateless contracts we can still give developers the ability to create unique applications while maintaining network performance.
Stateful and Stateless contracts are executed at different times. Stateless contracts can be run in parallel and in advance of block assembly. Stateful contracts are executed during block assembly which typically takes 200ms. The block assembly time slot is tightly controlled and must be for performance and ledger reasons. This is why Stateless contracts can be bigger and offer more opcode budget.
Not all operators can be used in both stateful and stateless currently. One, in particular, is ed25519verify which does signature verification. It is extremely expensive and we don’t allow it to be used in stateful contracts. In fact that one call takes about twice the amount of time to run than one stateless contract call. Smart Contract limitations are shown here https://developer.algorand.org/docs/features/asc1/teal/#operational-cost-of-teal-opcodes
By allowing linking of stateless and stateful contracts using atomic transfers, we give developers the ability to still create larger more complex applications without impacting performance. The team is working on many performance-related features and hope to offer even more in the future. I hope this helps in understanding. Your feedback is appreciated.