@Plasma initially was not intended to be the easy way out of the throughput constraints of Ethereum. Since the beginning of its formulations, Plasma made the problem of scaling a problem of constraints, rather than a problem of raw capacity. Secondly, rather than putting more computation on a base block, it actually limited what one could perform off-chain, to maintain a thin and critical promise: one should always be able, in any case, to safely make it back to Ethereum. It is that design choice that makes Plasma fundamentally different to many subsequent scaling methods--and also the confusion behind the availing of Plasma.
In its bare essence, @Plasma views Ethereum as a last resort of arbitration as opposed to an execution layer. State transitions, computation and order of transaction are offloaded into child chains. Ethernet merely has occasional commitments, Merkle roots that capture the state of such chains. This separation minimizes on-chain load significantly, at the price of Ethereum no longer ensuring the correctness of every transition. Plasma however, makes the assumption that wrong behavior will be confronted and not precluded. Scaling is the acknowledgement of such constraint.
Here the focus of @Plasma on mechanisms of exit comes into play. Since Ethereum does not authenticate all of the transactions, Plasma has to issue users with cryptographic and procedural means to redeem their money unilaterally. The peripheral features of exit games, challenge periods and fraud proofs are the backbone of the system. Each choice of design in Plasma: the presence of utxo-based the various forms of models, any constraint on smart contract expressiveness, buying out at a longer withdrawal time is dictated by the property that exit is predicably verifiable and executable on Ethereum in adversarial circumstances.
In this light, @Plasma is not throughput optimum in the traditional meaning of the term. It does not strive to maximize the number of transactions per second and still be completely general. Rather, it limits the functionality to the point that even the worst-case scenario can be survived. When an operator withholds data, bans users (or gives out incorrect state roots), the system does not crash completely, but instead enters the exit process. This scaling philosophy is much different than rollups in which Ethereum re-executes or re-verifies off-chain computation in order to ensure stronger guarantees.
These limitations are the cause of many of the real limitations of @Plasma . Smart contracts of general purpose are hard to support, as exits have to be expressible and challengeable in Ethereum. The availability of data is the assumption that is external and it implies that the users or watchers have to actively track the chain. The concept of mass exits, although hypothetically secure, creates the threat of congestion on Ethereum. All these are not some accidental shortcomings; they are direct outcomes of considering exit safety over the flexibility of the execution.
It is also a consequence of seeing @Plasma as a constraint system that it has not been the scaling solution of choice even though it is a beautiful thing to do. With the development of Ethereum, more models that replace the higher on-chain verification costs with easier user guarantees became accepted in the ecosystem. Rollups transfers more computation to the security model of Ethereum, so users do not need to act in the defense of their funds. Plasma on the other hand requires vigilance and is willing to tolerate complexity to be able to have small on-chain footprint.
But the ideas of @Plasma still have their effect. The isolation of the implementation and the settlement, the specific modelling of failure modes, the emphasis on a recovery reducing adversarial failure rather than optimistic performance all influenced subsequent designs. More to the point, Plasma is used to show that the scaling is not a one-axis optimization issue. The process of increasing throughput not specifying how systems fail and the users would escape the failures is not scaling but deferral.
In that regard, @Plasma is successful because it does not turn out to be a throughput shortcut. It causes protocol designers to grapple with awkward issues of operator trust, user responsibility and worst-case behavior. Ethernet can be scaled in numerous different ways, but Plasma is reminding us on the fact that before we go further with any other credible approach, we need to answer a more basic question: in case everything is going wrong, who will be able to make it out of the trenches and how?
