- UX of interacting with/running code. This isn't users going to a website or downloading an app from an app store. Until it is, it's a non-starter.
- Unsolved side-effects/data input. While "blockchains" are good at reducing the amount of trust needed in a system, for smart contracts to interact with the real world, they still need trust for data input/output. This all seems like it's in very early development.
- Inflexibility of contracts. "Paper" contracts, T&Cs, etc, have an advantage that they work 99% of the time, but that when you hit an edge case that no one has figured out before you can email someone and come to a resolution, or at worst, go to court to have a (hopefully unbiased) third party decide. This is often better for both parties, but is not an option with smart contracts.
- Development risks. Last time I checked smart contracts were written in a language that seemed to be inspired by a combination of C and Javascript. I'm not sure there's a worse way to write code that is so critical. Software engineering is decades ahead of this, safety-critical software engineering is many more decades ahead of that, and contract law is centuries ahead.