Django uses thread locals in some places where it's needed, but that's beside the point though. It doesn't put thread local objects at the core of its API. Passing an explicit request (real or fake) into functions is much more testable and generally better than relying on a 'request' global, IMO. Same with all the other app globals [1].
A better, more specific argument about Django's use of magic is the models. It uses some dark black magic voodo metaclasses to implement those. Apart from that, the forms, admin, app registry, urls, views is pretty straightforward.
But hey, it's personal preference. I like flask mostly: for some situations it is amazing.
1. http://flask.pocoo.org/docs/0.12/api/#application-globals
Also, putting things into thread locals somewhere makes explicit request objects totally pointless, because you still depend on threads and can't use Django in an async manner. So it's not a valid good technical argument either. You might like that better, but that's just a subjective opinion.
There are 5 other usages in total, one in the live reloader, two in the tests and two in GeoDjango.
Explicit magic is still magic, and Django contains surprisingly little magic of any type overall, including thread locals.