Thank you for the quick reply. 
I will try to explain my use-case: we keep a copy of all strapi data in another internal database (it is simpler to handle some logic from this other database).
We then need some data consistency between strapi db and internal db.
Each time an item is created/deleted through strapi content-manager, it must be created/deleted in our internal database. If an operation fails, everything should revert (~ saga pattern, i.e: if I create an item in strapi and the creation fails in our internal database, created item in strapi should be removed as well).
Lifecycle hooks completely cover the use-case for item creation, but it becomes harder for item deletion, especially bulk deletion.
When bulk deletion is trigger, afterDeleteMany only exposes deleted IDs. If for some reason, the deletion from our internal db fails, we must re-create deleted items in Strapi. And we can’t access them anymore as they are actually deleted. 
That’s why the idea of extending core controllers by wrapping logic around the actual action is more convenient in our case: we could fetch the whole data before actually deleting it, and trigger other action after the deletion…
I hope I am clear enough, and maybe you have an idea of how we could achieve such mechanism with V4…? 