ETFBitcoin is right, a total "loss" (as punishment) for the abuser is only possible if the abuse can be verified by the Bitcoin client.
The only way I see is to set nLockTime so late in the future that
de facto it will become a loss (e.g. several years) and the "normal" way would be to close the contract earlier.
You could slightly improve (but not completely solve) the incentive problem: Imagine an agreement between user and service owner where you initially agree to a very high nLocktime value, but with every week or so you use the service without abusing it, the service owner signs a transaction with a nLocktime value that expires earlier. However, this depends on the good-will of the service owner.
Making the abuse "verifiable" like in LN, however, in most cases is not practical. Imagine an e-mail service that is set up in a way that a public message, verifiable by every Bitcoin client, is broadcasted with every e-mail the user sends (you could even set up that in a way that the user must sign this message with every mail he sends, so the service owner couldn't cheat). If the user exceeds a certain "quota" he then could lose his Bitcoins. But in this particular case the service owner could simply configure his service in a way that prohibits exceeding the mail quota. It's hard to imagine a case where preventing "overuse" with a simple configuration is not possible.
(
This anti-spam solution I posted last year is very similar to the example in the Wiki, with the difference that no multisig is required.)
