There are some good criticisms mixed in along with some conflations of different ideas. I’ll try to address these as if you’re referring to Plasma Cash and the space of various derivatives. In the below points, if I say “Plasma Cash”, please read it as “Plasma Cash, and variants” 
.
Mass exits
- I believe Plasma Cash variant constructions eliminate the need for mass exits[0]. You may be thinking a different flavor of Plasma? I agree that this can get confusing
. My understanding is that in Plasma Cash, a user never needs to exit their coins to keep them secure, it’s only when someone else tries to invalidly exit your coins that you need to contest their exit before the challenge period ends.
History proofs are big
- There are various explorations into how to mitigate history sizes, from Plasma XT[1] checkpointing to various crypto-magic techniques including RSA accumulators[2] and various zk-s*ark techniques[3][4][5] that do things like reduce the history proof size or even eliminate its need.
Verifying a transaction is expensive for the receiver
- Maybe this is the case for some Plasma variants, but not for others. If you point out a specific case of this for a specific Plasma variant, there has probably research that has progressed that I can point you to that makes the situation a bit better
. Off the top of my head, for Plasma Cash, I think basic Plasma Cash would entail this kind of processing to validate the history of coins being sent in a transaction, but there are improvements I’m discussing in the other points that make this simpler.
Incremental payments aren’t solved
- See Plasma Debit[6] along with the various “coinslots are a numberline, send and own them as intervals/fragments” variants of Plasma: Plasma Prime[7], Plasma Cash Flow[8], etc. The upshot is that there are various ways to handle this in the works.
People can steal money that isn’t theirs
- In Plasma Cash variants (which seems to be what this post is about), every UTXO that is backed by an asset on-chain is owned by a user off-chain. That user is responsible for challenging any faulty exits of their assets within the challenge period.
Being a validator isn’t feasible
- I’m not sure what you mean here, it seems you think that validators only get paid when bad exits are challenged, which isn’t true. I believe that most of these variants we’re talking about entail fee payments to the operator of either small increments for the variants that easily allow that, or probabilistic payments of slightly larger increments for variants where small payments are harder.
There’s a lot here spanning a huge timeline of Plasma research that has gone on, and I’m not 100% that I interpreted each of your questions correctly, so forgive me if I slipped up in a few spots; happy to discuss anything that’s unclear.
All-in-all, I think the best criticisms are of user synchrony/liveness requirements (to challenge invalid exits) and large history sizes. That being said, I think there’s a path with zk-magic and coin-interval-style variants to take care of the history size, and most users have cellphones that are always online that could easily check once-per-week that all of a client’s coins are safe (plus you could do something like watchtowers). Given this, I’m fairly confident in the state and direction of Plasma.
[0] From https://www.learnplasma.org/en/learn/cash.html: “Plasma Cash was originally designed to address the mass exit problem in Plasma MVP.”
[1] Plasma XT: Plasma Cash with much less per-user data checking, basically checkpoints being posted on-chain that, once accepted, imply any prior history (ie. the user doesn’t need to keep any copies of history that is implied by the checkpoint)
[2] RSA Accumulators for Plasma Cash history reduction
[3] Validity Proofs + Plasma Cash = Simpler Exit Game/Coin History?, basically using zk-s*arks to reduce the history size requirements dramatically.
[4] Minimal fully generalized S*ARK-based plasma - #6 by vbuterin
[5] Non-inclusion zkSNARK for Plasma Cash and Cashflow history compaction
[6] Plasma Debit [ Learn Plasma ] - Plasma Debit solves the issue you’re describing by making each Plasma Cash “token” slot into a payment channel with the operator. Now, paying Alice a fraction of your token becomes easier, as you can use the operator as a proxy for any increment desired (simplifying a bit)
[7] Plasma Prime design proposal
[8] The best link I could find was this YouTube video: https://youtu.be/-8Jp7VjspQE ; but essentially, treat the space of all coin slots as a number line, and any adjacent coins you own/send can be considered a single “fragment” that can be treated as one larger coin that is the aggregate of the values. You can now eg. split this interval of coins to send only some of them, or exit them all at once.