1. Quite often you don't (I've built dozens of websites without needing Celery)
2. Even if you think you do there's often a much simpler solution that is enough for most needs (Use cron, spawn a process etc)
Celery is a big, heavy lump of code to add to most websites and it increased the deployment complexity.
Questions like: should I send this email in-line in the web request? Get a very easy answer: no, just stick do it later. Sure, sending an email is probably fine to do in-line for now, but months in you may realise that things are slow, that you’re sending emails and rolling back transactions later, or committing the transaction but losing the email that needed to be sent, or all manner of other annoying edge cases. Queues don’t solve everything, but they can be an ok answer to a lot of stuff for a long time.
For basic sites, yeah maybe not necessary, but a reliable background processing system has always been a significant accelerator in my projects.
Several developers like to overengineer and "go for celery" (also applies to other technologies with other uses) even for small things.
You don't need Celery to run a batch job every day for example. Or to even do some parallel processing.
"Oh but python multithreading sucks" do you know when it does not suck? When your thread is waiting on something else. Also there's the multiprocessing module with a lot of "batteries included" for basic use cases.
Not to mention (my biggest pet-peeve of Celery) is that it "forces" you to work with a task queue model. Not a data queue model. Sure, it helps a lot when you need that, but sometimes you just need a queue.
I've usually had to build a small python cron runner using croniter in previous systems - which I think is a pretty clean solution - it just deferred tasks to rq workers. But having direct support in the lib might be nice.