I think the issue is that the domain model has a delete function. Deleting records from a database isn't really core business logic in the sense that you are modeling a business process. Instead, treat this as straight-forward CRUD logic in a repository or domain service.
Deleting stuff from the database is not part of the core business domain. It is an infrastructure concern if this translates to physical deletes from a database. If your system is performing a soft delete, then putting this in a domain model could make sense, although I would argue that a soft (or logical) delete is not a delete. Ask your stakeholders what that really means to them. It could mean "Close", "Invalidate", or "Archive". The notion of soft delete is not something I see mentioned in your question, though.
In short:
- For physical deletes: implement this in a repository or domain service. It isn't business logic.
- For soft or logical deletes: clarify what this means from a business perspective and don't call the function "delete"; give it a name that is meaningful to the problem domain.
Only after correcting where things should be deleted would I reconsider the other operations on Organization and User.