Clear state reason

Why was decided that the clear state will delete the local state without the possibility from the smart contract logic to prevent it?

Ultimately, the user should have the final say on what assets/smart contracts it has opted in. Clear state gives the user more control over local storage in their account because the user can delete local storage for a particular application (as opposed to a smart contract having autonomous control over local storage in the user’s account).

Thanks. Could this be used for malicius attacks?

No; I think you’ve got this all wrong.
The local state stored in the user account is not controlled by the user. It’s being conrolled by the app creator, and ensures that the managed state for the app global and local state stays in sync.
This feature allows the app developer to deploy reliable and complete solution, where the entire state is controlled by the app creator.

The opt out for apps allows the user to coordinate with the app a clean way to “separate”. That’s all. One unique characteristic of this is that the clear program is allowed to fail, and the cleanup would occur regardless : this would protect the user from malicious and/or poorly written apps.

Yes this is clear, but let’s say a smart contaract writes a useful information in the local state of the address. That address clears it. Now the smart contract has lost that useful information without acting in any way. This could also be used as an attack if the contract has not a way to check otherwise.
Let’s say I have a bank smart contract that let the user deposit and then withdraw 10% of the pot a single time (a stupid one but it’s an example). When user withdraws the smart contract sets a flag on the local state. Than it checks if the this flag exist or not to perimit a whitdraw. If the address clears his state he can whitdraw again and doing it for ever emptying the pot. I know this can be done in other ways (so for example when the opt in is done set that flag to 0 and than it checks if the key exist or not) but this adds some other complications during developing. Is my view correct or not?

Yes, I think that the use case you brought up is a good example… for a bad design decision. What you want to store in the user account is the user credits instead of the user limits. Otherwise, the user can open a new account and pull more funds from there, right ?

yes, really bad. of course it’s up to the dev using the algorand smart contracts tools accordingly