DRF is old and API looks more like Django forms or class-based views, more of an OOP hierarchy going on, and DRF serializers are slow
Not arguing here about types and Pydantic being faster than the built in ModelSerializers. However, for serializer speed improvements and performance in DRF I would advise dropping ModelSerializers and either going for Serializers or plain dict. Haki Benita has a beautiful article on that [0]. I was able to accomplish sub 200 response times on a fairly large response from tables that had tens of millions of records.
I think you have no objective reason other than your styling and rather personal preference for function based views?
I prefer Ninja over DRF, but I know plenty of orgs who still love their class based DRF views as once you are over the (significant) mental hurdle of understanding all the abstraction there, it does give you the common CRUD type operations on your models "for free".
With django-ninja you just define your APIs with annotated types as methods, there is no magic, and then you get a generated OpenAPI spec.
this was my experience anyway, I used DRF for this project [0] and ninja for this one [1]
In recent times I'm a fan of Starlette, which is what the popular FastAPI lib is built on top of, and created by same author as DRF.
Nowadays I just use PostgREST for all my new APIs. It's a phenomenal piece of software, save me so much time.
PostgREST uses the roles and privileges of PostgreSQL to verify if a request is allowed. So, while you can indeed add a PostgREST on top of the schemas generated by Django ORM, you would still have to manually create those roles, grant them some privileges and them assign those roles to your existing users (I'm not familiar with Django but, I guess, that would mean adding a field "role" to the Django model, applying the migration and then manually filling the column "role" in DB with the role you wanna give to each user). And then you would need a login endpoint that returns a JWT token containing the role assigned to this user, and then use this JWT token for all your requests. That's how auth and permissions work in PostgREST and it's one of the big benefits of using it IMO.
Also, I personally like to make views and expose those views to the PostgREST API, instead of exposing directly the tables. But exposing the tables generated by Django ORM would work too.