Most of the cost comes from the need to maintain consistency in state. This means that even simple database updates require a lot of work updating hash trees and verifying that other nodes reach the same results. The design of these hash trees isn’t terribly efficient, and indeed was in some ways designed to be deliberately inefficient in order to ensure that nodes didn’t fragment into running specific contracts.
The good news is that there’s a lot of room for improvement in the design. The bad news is twofold: (1) efficiency improvements will eventually cause transaction processing to be data-bound rather than compute-bound, and (2) these improvements to improve compute may be incompatible with existing Ethereum nodes. ZK and optimistic rollups potentially offer a way out of this update mess that don’t require dramatic changes to the underlying consensus system. However they will also inherit some of the limitations above, including tradeoffs between availability and processing speed.
This is probably the first reply I've seen that doesn't shy away from saying "yes, we're inefficient", and looking at the solutions with a critical eye.
The good news is that there’s a lot of room for improvement in the design. The bad news is twofold: (1) efficiency improvements will eventually cause transaction processing to be data-bound rather than compute-bound, and (2) these improvements to improve compute may be incompatible with existing Ethereum nodes. ZK and optimistic rollups potentially offer a way out of this update mess that don’t require dramatic changes to the underlying consensus system. However they will also inherit some of the limitations above, including tradeoffs between availability and processing speed.