Mnie się zdarzało już co najmniej parę razy nadpisywać działanie jakiegoś generic view poprzez napisanie własnej funkcji, która z tamtego korzystała.

Dajmy na to prosty przykład: chcemy mieć podstronę wyświetlającą informacje o jakimś obiekcie, ale tylko dla osób zalogowanych. Nie możemy skorzystać z django.views.generic.list_detail.object_detail, więc co, piszemy wszystko od początku? Nie, tworzymy funkcję, która nie robi nic innego, tylko wywołuje object_detail z tymi samymi parametrami, traktujemy ją dekoratorem login_required i już. Właściwie, to z naszej nowej funkcji możemy teraz korzystać jako z nowego generic view, wykorzystywać wszędzie, gdzie chcemy mieć object_detail tylko dla zalogowanych

(właściwie, to dla pojedyńczej sytuacji nawet nie trzeba tworzyć dodatkowej funkcji - w samym urls.py można od razu wstawić funkcję dekorującą z naszym object_detail jako parametr)

Podmienianie danych POST to już co innego - tu faktycznie stosujemy brzydki trik i przymus jego wykorzystania faktycznie jest spowodowany brakami w django.contrib.admin, ale jeśli chodzi o samo modyfikowanie widoku admina… to wydaje mi się jak najbardziej normalne.

Aha.
Jeśli mogę się przyczepić, to uważam, że jeszcze jedną rzecz mógłbyś zrobić dużo lepiej.
Normalna funkcja add_stage z admina przyjmuje w parametrach nazwę aplikacji i modelu. Ty, nadpisując ją, pozmieniałeś te parametry, co wydaje mi się zupełnie bez sensu - to chyba normalne, że jeśli coś dziedziczymy, czy nadpisujemy, to staramy się zostawić na wejściu i wyjściu dokładnie to samo?
Dużo lepiej by było, gdybyś zrobił tak:

return main.add_stage(request, *args, **kwargs)

Po prostu tak - standardowa zasada przy nadpisywaniu: “co przyszło, to wyjdzie”, czyli wszystko załatwiają za nas świetne *args, **kwargs Pythona.
Oczywiście w takim razie i do nadpisującej funkcji muszą przyjść odpowiednie parametry. W takim razie modyfikujemy jeszcze urls.py:

(r’^admin/(aplikacja)/(model)/add/’, ’serwis.aplikacja.admin_views.add_stage’)

lub dodajemy nazwy ‘aplikacja’ i ‘model’ w słowniku w trzecim parametrze, choć to pierwsze rozwiązanie dużo lepsze.

Zyskujesz na tym:
1. Możliwość wykorzystania dokładnie tej samej modyfikacji dla innej aplikacji/modelu, gdybyś kiedyś chciał.
2. W cholerę i jeszcze trochę logiki, poprawności programistycznej, czy jakkolwiek tego jeszcze nie nazwiemy.