First, django-allauth supports an impressive list of providers. FusionAuth can support most of them using our generic OIDC connector, but kudos to the django-allauth team! If you are sure you only are building one django app, it's a good choice (and way better than rolling your own auth lib--please don't do that).
I'm not super familiar with django-allauth, but I did a bit of research. I think the reasons to use FusionAuth rather than django-allauth are:
centralized user management and control, even if you use a social provider. This scales to multiple applications within one tenant (so a django app and an open source forum app like nodebb can share a userbase; each user has the same username/email and password for each app) and multiple tenants (so you can have django app A and django app B totally separated, with different usernames/emails and passwords, if you're whitelabelling your app)
ability to integrate with other auth providers using non OAuth protocols, like
SAML
FA is a single app, as opposed to a set of extensions you need to find, merge together, and keep in sync. You just drop it in and it works.
additional features that you might not know you need until you need them (and have to build or evaluate/integrate a different library):
passwordless
consents
family grouping
webhooks for integration on user changes
user actions
groups
jwt generation
DAU/MAU reporting
2fa (I saw a 2fa plugin for this, but it was supported version 0.25 and django-allauth is at 0.42)
In short, FA is a full user management system, as opposed to an authentication and authorization plugin like django-allauth.
