Plasma is naturally more suitable for "payments" rather than "complex calculations". It's not that the performance is insufficient, but from day one, it was not intended to bear complexity.
The core assumption of #Plasma is very simple: off-chain will commit fraud, so the main network is only responsible for adjudicating "right or wrong", rather than recalculating every process. This determines that it is best at handling clear results and well-defined state changes—who gave how much money to whom, how the balance is transferred, it can be judged at a glance. In contrast, complex calculations rely heavily on numerous intermediate states, conditional branches, and context for their correctness. Once these are placed off-chain, the main network can hardly verify without recalculating.
This is also why @Plasma commonly adopts #UTXO or simplified account models. It's not a lazy design, but rather to make "challenges" feasible. If a payment fails, you can present a double-spending proof; if there's an error in contract logic, it's quite difficult to use a small piece of evidence to demonstrate that "this entire calculation is wrong". Once the proof cost spirals out of control, Plasma's security model collapses directly.
Another often overlooked point is that complex calculations imply a high degree of state coupling. If one variable is wrong, it may chain-react to affect a large number of states; whereas Plasma's exit logic precisely requires states to be separable, claimable independently, and withdrawable on their own. Payments naturally meet this condition, while complex contracts almost structurally do not.
Thus, Plasma leans towards payments, not because it chose a conservative technical route, but because it clearly understands its boundaries. It trades minimal verifiability for survival capability under extreme security assumptions. Complex calculations are not impossible, but they are not worth pursuing within the logic of Plasma.