Siz User nomli model yozgansiz, ammo djangoning o'zida ham shunday nomli model bor.
Hozir user login qilganda siz yaratgan model objecti sifatida emas , djangoning defaul User modeli objecti sifatida kirayapti.
Sizda (kamida) 2 ta variant bor:

1. Modelingizga boshqa nom berish(masalan, Profile) va uni one to one relationship orqali default User modeliga bog'lab qo'yish.

2. Custom User model yozish. Bu nisbatan qiyinroq, ammo siz kutgan natijani beradi.

Birinchi usul odatda, userning ma'lumotlarining bir qismini alohida saqlashda ishlatiladi.
Masalan, o'qituvchi uchun model yaratmoqchisiz. Uning ismi, yoshi o'qitadigan fanlari, sinflari, maoshi kabilar alohida modelda saqlanadi.
Email, username password kabi faqat login uchun kerakli detallar User modelida qoldirilib narigi model bunisiga ulanadi.

Umuman olganda, sizning User modelingizdagi barcha fieldlar default User modelida ham bor.

pre_save bu signal. Model objectining save() methodi chaqirilishidan oldin biror boshqa kodni yurgizadi. Menimcha hozir boshqa narsani so'rashdi. Yana bilmadim.

Agar server kuchsizroq bo'lsa, bitta appni ko'plab alohida portlarda ishga tushirish ham yaxshi natija bermaydi(CPU bilan RAM requestlarga turib berolmasa).
Iloji bo'lsa hardwareni ham bittadan ko'paytirish kerak.

Biladiganlarim bo'yicha aytadigan bo'lsam,

Qachon ishlatmaslik kerak:
1. WHERE bilan ishlatilganda too many rows qaytaradigan querylarda(masalan, ManyToManyda).
2. Ko'p yangilanib turadigan columnlarda(masalan , mijoz hisobidagi mablag').
3. Mumkin qiymatlar soni cheklangan holda(masalan, django fieldda choices ishlatganda).
4. Bir xil qiymatli(shu jumladan null) rowlar ko'p bo'ladigan columnlarda (1- va 3- bandlardan kelib chiqib).
5. Rowlar soni ko'p bo'lmagan tableda

Qachon ishlatish kerak:
1. WHERE bilan ishlaganda odatda 1(yoki juda kam) ta row qaytaradigan querydagi rowlarda(SELECT * FROM users WHERE email = 'example@gmail.com' (UNIQUE bo'lsa database o'zi index qo'shadi).
2. WHEREda odatda birga ishlatiladigan fieldlar uchun multicolumn index (masalan, authentication uchun odatda username bilan password birga ishlatiladi).

Va ANALYZE qilish. Django qanchalik ko'p analyzedan foydalanishi haqida xabarim yo'q.
Har safar nimadir implement qilib, oldingi performance bilan compare qilib ko'rish. Bu orqali qaysi usul ko'proq foydali ekanini va qayerda ishlatmaslik kerakb bilib olasiz.

P.S. Bu faqat shaxsiy izlanishlarim :-)

Bitta conceptni tushunishingiz kerak:
User(va boshqa model) objectlari ham databaseda saqlanadi, admin panel yoki boshqa pageda emas. Ular faqat databasedan olib, chiqarib beradi.
Demak, ma'lumotlar bazasidan o'chirish userni admin panel yoki boshqa pagedan ham o'chiradi.
Bazadan o'chirish uchun o'sha user objectini olib, uning delete() methodini chaqirishimiz kerak.
User objectini esa templatedan kelgan user.id orqali olamiz. Bizda user.id bor, eni user objectini olamiz:

user = User.objects.get(id = id)
# ikkinchi id biz templatedna olgan id.
user.delete()

Dasturchilar orasida "Googling is a skill." degan ajoyib gap bor.
Ya'ni qanday izlashni bilish ham bilim, hatto san'at.
Bu ishingizni nohoyatda yengillashtiradi.
Google bilan do'stlashib oling :-)

urls.py ni ko'rsatingchi.
Aftidan, delete urldan teparoqda dynamic (slug, id kabi) url bor va siz jo'natgan request o'sha urlga "tiqilib" qolgan.
Ya'ni urlda "delete/" deb yozgan bo'lsangiz ham shu urlga kelayotgan request teparoqdagi "<int:id>/" dan o'tib keta olmayapti.
Agar shunday bo'lsa, dynamic urldan oldin boshqa kalit so'z(masalan, "detail/<int:id>/") ishlating yoki dynamic urlni eng oxiriga qoldiring.