Cascade deletion never made much sense to me.
It's not just about wanting to state intentions explicitly but about understanding the data relationships.
If you don't know how things are working, maybe you should not be the one doing the deletion?
Also, how often do you even have to write a delete command?
There are many ways to CREATE, but there is always one DELETE.
Just one.
Soft deletion looks different, but it is very similar.
You want your data gone, but you still don't want to bother to understand the data relationships.
You just flag the entity with IsDeleted.
And the deleted things keep popping up.
There are many ways to SELECT too, and you have to update all of them.
Let it go
It's just clutter.
Chaotic mess that did not survive data schema change five years ago.
Just one more thing to index, backup, and maintain.
The Void is here, and it is real.
Maybe someone has deleted it by accident? Maybe, they will want it back?
If the thing should even be deletable, how much damage can you make since the last backup?
But we have to track who deleted it?
Then track who deleted it as a separate concern it is.
Even better, do the proper audit trail identifying who, what, when for every data change, not just deletion!
You don't have to do anything fancy, like giving users the option of restoring the previous state and just store every command for audit purposes in a separate system. It's cheap and easy. And one day, if it makes sense - do more!