I’m so glad to see people loving django.tasks! 
There are a few things not quite right in this post:
For now, Django 6 only contains some reference code, which can not be used in real projects.
This isn’t quite true. What’s in Django 6.0 is definitely final code which is useful, it’s just a proper execution backend which isn’t included. For example, the @task decorator included works absolutely fine (including with 3rd-party backends).
Similarly, given that, you can update most of your imports to from django.tasks import task. In 6.0, only the backend needs to be pulled from django_tasks.
Supported Brokers Database (built-in), Redis (via third-party backends)
Technically both the RQ-based and database are as built-in as eachother. The main difference is that whilst there’s an intention to eventually upstream the database backend, the RQ one will almost certainly always live externally.
Task Priorities Limited (via queue separation)
django-tasks supports integer priority for tasks (at least on the DB backend). You can also do dedicated capacity via queue names (which you’ve covered in “Flexible Routing”).
The RQ backend doesn’t support priorities, but that’s a limitation of RQ itself.
Community & Maturity New (Django 6, 2025)
The first version of django-tasks was in early 2024, and supports right back to Django 4.2. Sure, that’s nothing compared to Celery, but I know it’s been used in production since not long after that time.
Don’t need distributed task processing
You can absolutely use django-tasks in a distributed fashion. For the database backend, multiple worker processes are supported, and can easily run across multiple machines. They only need the codebase and access to the database.
I’d love to know if there are places we can improve the documentation to make some of these limitations clearer, or make some of its features more evident.