Delete is a destructive action. Some systems are good in allowing you to undo deletes (e.g. email), but majority don't have undo actions and so when something is deleted it's gone for good.
Going by the principal of "poka yoke" (mistake proofing). You want to design the interface to reduce unintentional deletion of data. Having the delete action within the edit screen is one way of doing so. A user must deliberately decide to go into edit, then choose delete to remove an item.
There are other ways of mistake proofing
- delete confirmation modals if delete is on the record list (which can be annoying if the user have to do many consecutive deletes)
- ask user to check off record rows, then access contextual menu to delete
- Soft deletes (allow user to undo deletes within X period of time)
In terms of other actions like reset password, disabling account etc. The question to ask is how frequently would a user need to perform such action? Actions that don't occur regularly doesn't need to be accessible directly on the record list. In fact, it's best not to have them there to unclutter the UI so more frequent actions stand out.
Another thing to ask is would the user need to perform that action on multiple records? A record lists makes it easy for you to put in bulk actions where you check off the rows you want changes on, then choose the action you want to apply to selected rows.