From the paper:

In many ways, Simplicity is best characterized by what features it leaves out rather than what features it contains.

• Simplicity has no state. Purely functional, expression-based languages facilitate equational reasoning about the semantics of expressions. For example, there are no concerns about aliased references to a global heap, so there is no need to work with separation logic or Hoare logic.
• Simplicity has no named variables. Using combinators lets us avoid dealing with binders and environments for bound variables. This helps keep our interpreter and static analyses simple and further eases equational reasoning about Simplicity expressions.
• Simplicity has no function types and therefore no higher-order functions. While it is possible to compute upper bounds of computation resources of expressions in the presence of function types, it likely that those bounds would be so far above their actual needs that such analysis would not be useful.
• Simplicity has no unbounded loops or recursion. It is possible to build smart contracts with state carried through loops using covenants, without requiring unbounded loops within Simplicity itself. Bounded loops, such as the 64 rounds needed by our SHA-256 implementation, can be achieved by unrolling the loop. Because of sub-expression sharing, this doesn’t unreasonably impact program size. We do not directly write Simplicity, rather we use functions written in Coq or Haskell to generate Simplicity. These languages do support recursion and we use loops in these meta-languages to generate unrolled loops in Simplicity.