Definitely a dalicate issue. I hope I can answer so that anyone (regardless of their technical knowldege) can understand.
If buyers are scared of buying and sellers are scared of selling then there will be less plugin and themes around. We all lose. I'm going to explain this in very simple terms. I can see 4 different scenarios here based on honest/dishonest and buyer/seller combinations. The goal is that honest buyers (ideally) get the product they look for or (at least) don't lose the money and honest sellers (ideally) get the money and (at least) don't give a working product for free.
I don't think the goal can be achieved by any system. The only way is being good people and acting ethically. Assuming the world won't change from one day to the other, I will answer trying to decrease risk as much as possible to both sides (it is very important to keep that in mind).
Now, it seems this simple rule, 100% based on common sense, is clearly not respected by PayPal allowing dishonest buyers to ALWAYS get back their money AFTER receiving a working product. This absolutely breaks the rule in favor of clients.
I'm not going to defend the opposite either. If PayPal did not allow clients to refund their money on digital purchases the rule would still be broken again, this time in favor of sellers.
In any case, PayPal has chosen a side, so there is no point in arguing what should PayPal do or not but rather how can we lower the risk from both sides as much as possible.
So PayPal allows clients to always refund payments for a 60 day period after the purchase. Clearly, if a seller gives a working product to al client before those 60 days, they will be in this same situation in which dishonest clients can always get their money. Following this reasoning (and this is the part where I get the downvotes) clients can not receive a fully working product in those initial 60 days.
But here is the catch. By a not fully working product, I don't mean buggy or with less features, I just mean a kind of trial version that will stop working after 90 days (this is the part in which you whish you could double downvote my answer). In day 61, if the seller does not get a refund request, then he sends the fully working version of the product. In this schema, clients can do whatever they want during the first 60 days. If they are dishonest they will refund and after 90 days the product will no longer work (no gain for them). If they are honest and don't like the product, again, they can refund and they will not keep the fully working product.
Of course, this raises this obvious issue: an honest client wants to keep the product after those 90 days and then the risk will be on his side instead of the seller. True (downvote tsunami). But here I'm going to play again my "decrease risk" card. After those 60 days, the seller knows nothing about the client. And you might be tempted to think the buyer knows nothing about the seller but this is not true. The buyer DOES know the seller created a product that satisfies his needs. It is there, the client is already using it.
In this approach the rule can still be broken. However, the risk of it being broken is considerably decreased. The seller does not gain anything from not sending the fully working product on day 61. The seller already has it and it just means sending an email, providing a download link or whatever. As a side note, the seller might also lose future sales or even reputation in this forum, if he uses it.
So this is just a suggestion or idea to get rid of dishonest clients (dishonest sellers are already handled by PayPal's refund policy). This should only leave honest clients and honest sellers (including both, the ones who will send the fully working product on day 61, which they had already developed, and the ones who don't).
For developers: I guess these trial versions can be the original code, including a few time checks and then obfuscating the code. I'm not sure if there is another approach to this when using PHP but it should work for most users. Even if they are developers and manage to deobfuscate the code, they will have a bad time debugging it if the code is long enough :)